feat: isolate hardware factory and test APIs

[wabicai]

What

• add @onekeyfe/hd-test-api as the separately publishable package for factory and automated hardware-test methods
• add a generic Core method/protobuf extension SPI with destructive-operation authorization
• remove non-production factory/test methods and protobuf definitions from the production Core API
• keep deviceReadSEPublicCert and deviceSESignMessage in CoreApi for the production verification flow
• expose factory, debug, and test commands through one extension registry and one schema fragment per protocol

Why

Factory and automated-test workflows need access to private hardware commands without exposing those commands through the production HD Core surface or shipping their protobuf definitions in the production schema.

Impact

• production consumers keep the two secure-element methods required by deviceVerify
• factory/test consumers opt in through @onekeyfe/hd-test-api
• destructive write/erase/provisioning methods remain disabled unless explicitly authorized
• the Common SDK lifecycle remains process-global, so one SDK instance should be used per JavaScript runtime

Checks

• built @onekeyfe/hd-transport, @onekeyfe/hd-core, @onekeyfe/hd-common-connect-sdk, and @onekeyfe/hd-test-api in dependency order
• 6 focused Jest suites / 21 tests passed
• tsc --noEmit -p packages/hd-test-api/tsconfig.json
• scoped ESLint passed
• yarn check-versions passed for all 31 packages
• git diff --check passed

No physical hardware write, erase, provisioning, or firmware operation was executed.

Known draft state

factory/api advanced after this worktree was created and GitHub currently reports a merge
conflict. The new base includes DeviceFactoryPermanentLock; syncing it requires an explicit
follow-up migration of that newly added factory API into this package and revalidation against the
latest protobuf schema.