fix(models): preserve upstream reasoning capabilities for offerings - #149

Problem

Host-managed model offerings lose their upstream capabilities in the frontend. HostProvider.refreshModels synthesizes an opengui-offering connection with only { displayName, reasoning: true }. Consequently, connectionsToModelProviders falls back to none/high even when the upstream catalog declares a different supported effort list.

Looking up capabilities solely in the frontend would not work for members: their offering payload intentionally omits backend and upstream model IDs.

Fix

• Resolve each visible offering on the backend using the existing actor-authorized resolveModelOfferingForUse path.
• Project only reasoning, reasoningEfforts, and context from the global Host connection's upstream metadata. No endpoint, credentials, compatibility options, or additional route details are exposed.
• Extend the frontend offering type and use offeringsToModelConnections to preserve capabilities through the picker projection.
• Keep the existing fallback when upstream metadata is unavailable. No hardcoded expansion of reasoning levels, entitlement changes, catalog edits, or translation changes.

Regression coverage

• Member route response carries the exact supported efforts/context and no upstream/private fields.
• Offering → synthetic connection → picker provider preserves minimal/low/medium/high/xhigh/max and context.
• Both new regression tests were observed failing before the fix, then passing.

Validation

On current upstream master (9b82159):

• pnpm vp check: passed (format, lint, types).
• pnpm run slop-check: passed.
• Eight targeted suites: 150 passed, 1 failed out of 151 tests.
• The failing pre-existing test is personal-subscriptions.integration.test.ts → uses the Host Codex credential for an entitled offering when the member also has personal Codex, at memberModels[0]!.id (line 379). Re-ran that suite on unchanged master with the entire PR patch removed: the same failure. Not addressed here to keep this PR focused.
• On the deployed v0.6.2-based source, all 151 targeted tests passed and the production build succeeded.

Deployment note

The same focused fix is already deployed on our self-hosted instance in a derived Docker image preserving existing deployment customizations. Health check and public HTTP returned healthy/200. No authenticated owner/member browser verification was performed; that remains a manual check. Deployment-only files and operational lock cleanup are not included in this PR.

Manual verification

1. Sign in as an owner and as an entitled member.
2. Select a Host offering whose upstream metadata specifies supported reasoning efforts.
3. Confirm the picker shows those exact efforts, not the default none/high pair.
4. Check a non-reasoning offering, an unknown-metadata custom model, and personal subscriptions retain their previous behavior.