Init-time HEDGE default has never reached the exchange (set_position_mode no-ops with trading_pairs=[])

Summary

Follow-up to #207/#208 (dynamic-pair state family), split out of PR #209 deliberately.

UnifiedConnectorService._create_and_initialize_trading_connector() sets a HEDGE default on perpetual connectors at init:

if PositionMode.HEDGE in connector.supported_position_modes():
    connector.set_position_mode(PositionMode.HEDGE)

At that exact moment the connector was just created with trading_pairs=[], and the py-base _execute_set_position_mode logs "No trading pairs configured, cannot set position mode." and returns — so this call has never reached any exchange. The intended mode is not persisted anywhere (_perpetual_trading.position_mode is only updated on success), so it cannot be retried later.

Consequence

Perpetual accounts run in whatever mode the exchange already had (account default or last manual setting), while the API's code reads as if HEDGE is the guaranteed default. Executors then compute position_action under one assumption and the exchange enforces another, surfacing as order-time errors far from the cause.

Why PR #209 does not fix this

#209 makes the endpoint honest (registers a provided pair, 400s instead of silently succeeding), but deliberately leaves the init-time call untouched: making it suddenly effective would flip long-running accounts from their current exchange mode to HEDGE on the next API restart — a live-behavior change that deserves its own decision, not a rider on a bugfix.

Suggested direction

• Record the intended mode at init (e.g. pending_position_mode) instead of firing a call that cannot work, and apply it on the FIRST pair registration for the connector (sync_pair_derived_state from #209 is the natural hook). The base _execute_set_position_mode already fetches the exchange mode first and no-ops when it matches, so re-firing is idempotent.
• Decide explicitly whether a silent HEDGE default is even desirable, or whether mode should only ever be set through the (now honest) endpoint.

Related: hummingbot-api-client needs a trading_pair field on set_position_mode to use #209's registration path directly; until then callers must set leverage first (which registers the pair) or pre-add the market.

Start at UnifiedConnectorService._create_and_initialize_trading_connector and the py-base _execute_set_position_mode path, then trace sync_pair_derived_state from #209. Resolve whether the init-time HEDGE intent should be retained and applied on first pair registration or removed in favor of the endpoint. Done means the chosen policy is explicit and the mode request is not silently lost when trading_pairs is empty.