fix(mobile): read the model catalog shape the Harness actually serves

[smarthomeblack]

Problem

Two bugs in the mobile session-settings panel (Model selector), both caused by the page reading a field shape session/modelCatalog does not serve:

1. The Model select is permanently disabled. syncSettingsControls computes model.disabled = settingsBusy || !modelCatalog?.routable, but the catalog has no routable field — it serves routableProviders: string[]. !undefined is always true, so the select can never be enabled.
2. The displayed model is wrong. renderSessionSettings reads modelCatalog.current, but the catalog serves default: { provider, model, reasoningEffort? }. current is undefined, so no <option> matches and the select falls back to rendering the first catalog entry instead of the model the desktop is actually running.

Verified against the host contract (@deepseek-ai/dsh-api-session-controller typert schema):

modelCatalog = {
  default: { provider, model, reasoningEffort? },
  routableProviders: string[],
  groups: [...],
  failures: [...]
}

and against a live Harness: GET session/modelCatalog returns exactly that shape (default = the selection actually in use, routableProviders non-empty).

Fix

In lan-mobile-pages.ts, read the real shape with a fallback for older builds:

• current selection: modelCatalog.current ?? modelCatalog.default ?? {}
• routable: (modelCatalog.routableProviders?.length ?? 0) > 0 || modelCatalog.routable === true
• the RPC-failure fallback object now uses the real shape (default + routableProviders: [])
• after a successful session.selectModel, both current and default are updated

Test

• node --check on the extracted page script: syntax OK.
• Patched a local install with the same change: after a full app restart the mobile Model select becomes enabled and shows the running model (default) correctly.

Note

session/modelCatalog takes no session argument, so default is the host-wide last/default selection, not a per-session override. Mobile can only display that value; per-session display would need a host API addition (out of scope here).