bug(browser): forward preferredContextId through health and readiness routing

[lyc10031]

Summary

#2073 introduced preferredContextId so a persisted default is a soft preference rather than a strict requirement. Command dispatch forwards it, but the health/status/readiness paths still drop it. This makes the configured default ineffective before command dispatch and can make opencli doctor or browser startup return profile_required whenever two Browser Bridge profiles are connected.

Reproduction

1. Connect two Browser Bridge profiles.
2. Run opencli profile use <one-profile> so ~/.opencli/browser-profiles.json has that defaultContextId.
3. Run opencli doctor (or a browser command that reaches ensureBrowserBridgeReady()) without --profile.

Actual

The status/health request contains neither preferredContextId nor the persisted default. /status resolves with no selection and returns profile_required; doctor reports that no default is selected even though one is configured.

Expected

The persisted default should remain a soft preferredContextId through health, readiness polling, /status, and doctor. With the preferred profile connected it should be selected; if stale, retain #2073 behavior: fall back only when one live profile exists, otherwise require an explicit choice.

Evidence

• profileRouteParams correctly distinguishes explicit contextId from soft preferredContextId.
• BrowserBridge.connect() drops routing.preferredContextId when calling _ensureDaemon.
• fetchDaemonStatus / getDaemonHealth accept only contextId.
• waitForBridgeReady and ensureBrowserBridgeReady forward only contextId.
• /status parses only contextId, while /command already carries both route fields.
• runBrowserDoctor() calls bare getDaemonHealth().

Relation to existing work

This is not #1575 (formatter wording) and not the stale-default arbitration addressed by #2073 / #2081. It is the remaining pre-dispatch health/status propagation gap.

I reproduced this with two connected profiles and a persisted default; forwarding the soft preference end-to-end fixes the health probe while preserving the strict-vs-preferred semantics added in #2073.