Refactor: per-call V1 message schema selection instead of process-global TransportManager state

Follow-up from #884 review (P2: schema resynchronization is not atomic with Initialize).

Problem

TransportManager holds the parsed V1 protobuf schema as process-global state (currentMessages), and every V1 encode reads it at call time. When two V1 devices that require different schemas (e.g. a legacy-firmware Touch/Mini alongside a modern Pro) run calls concurrently, a reconfigure for one device can land between another device's schema sync and its encode, so the message is encoded with the wrong schema. The protobuf encoder silently drops payload keys absent from the schema, so fields like passphrase_state / is_contains_attach can be stripped without any error.

This race predates #884 (the alpha.129 GetFeatures preflight had the same non-atomic reconfigure → typedCall shape, and every other V1 call site encodes against the global schema without holding it). #884 narrows the practical window by re-syncing immediately before the Initialize encode, but does not close it.

Proposed fix

Thread the schema through the call instead of mutating a singleton:

• Resolve the schema per device (from its Features) once, store it on the Device / DeviceCommands instance
• Pass it through TransportCallOptions down to the transport encode/decode
• Keep the global only as a default for pre-Features calls (enumerate/probe)

Add a concurrent regression test: two V1 devices with different schema requirements issuing Initialize simultaneously; assert both wire messages contain their full payload fields.

Start with TransportManager and trace how Device or DeviceCommands resolves Features, how TransportCallOptions reaches transport encode/decode, and how Initialize is encoded. Store and thread the per-device schema while retaining the global default for enumerate/probe, then add the concurrent regression test described in the issue and verify both V1 wire messages retain their full payload fields.