Track model and service-tier provenance for managed and unmanaged threads

[galligan]

Context

Dispatch can observe model/reasoning metadata for threads, but existing Codex Desktop/App threads may not expose the effective service tier in persisted thread metadata. A missing service_tier field must not be interpreted as Standard/default mode.

Scope

Make thread reporting honest and useful by separating observed per-thread facts from configured defaults and Dispatch-owned intent.

Acceptance criteria

• For Dispatch-created managed threads, store the requested service tier and resolved app-server service tier when known.
• For unmanaged/existing Codex threads, report service tier as unknown unless directly observed.
• When possible, include effective configured default/catalog information separately from observed per-thread state.
• list, get, sync, and JSON outputs do not imply default/standard mode from missing thread metadata.
• Tests cover managed requested/resolved tier storage and unmanaged unknown/configured-default reporting.
• Documentation and skills teach agents not to infer Fast/default state from rollout service_tier: null.