beta client update banner advises 'omp update' off the pinned release

[alphastorm]

Observed on the published omp-18.0.9 beta client during the v0.2 demo recording: startup shows

Update Available
New version 18.0.10 is available. Run: omp update

For this product's channel that is misleading: the client is a hash-pinned release asset bound into the ready manifest, and omp update would replace it outside the release-integrity procedure (checksummed archive + manifest-bound cask revision). A tester following the banner silently leaves the qualified combination while everything still looks supported.

Scope: client integration (the fork build carries the banner; its issues are disabled, so tracking here where the channel contract lives).

Candidate fixes for the next accepted client build:

1. Channel-aware suppression: no update banner when the build identifies as the NInfer beta channel; or
2. Channel-aware copy: point at the pinned upgrade procedure in the quickstart instead of omp update.

A channel-aware update-check gate is also a reusable piece worth including in the upstreaming intent toward can1357/oh-my-pi.

[alphastorm]

Disposition after the 2026-08-30 upstream watch: root cause confirmed - upstream shipped 18.0.10 (08-28) and 18.0.11 (08-29), and the pinned 18.0.9 client has no channel awareness, so the banner advises omp update off the hash-pinned release. The NInfer provider, status validators, and checkpoint endpoints are all downstream patches (they do not exist upstream), so a client change only lands via a re-pin of the patched client.

Plan of record: stays open as the tracking issue; QUICKSTART already carries the do-not-run-omp-update warning for lane installs; the channel-aware suppression rides the next client re-pin evaluation (18.0.11+ was reviewed as low-risk UX-only: autocomplete acceptance, status timer, composer/gallery filters - no provider or schema movement).

[alphastorm]

Fixed and shipped in v0.6.6 (product release https://github.com/alphastorm/omp-ninfer/releases/tag/v0.6.6).

The config every documented client route installs - examples/manual-tunnel/fail-closed.yml, copied to ~/.omp/agent/config.yml - now carries:

startup:
  checkUpdate: false

Candidate fix 1 from this issue (channel-aware suppression), applied at the only layer this product controls: the pinned client's own setting. The nested form matters - a dotted startup.checkUpdate: key parses as an unrelated setting and leaves the default on; a test refuses any other shape.

The quickstart's warning now states what the config does and how to upgrade (clone the next tag, rerun the install step) instead of pointing at this issue.

Verified by re-running every client-installing route from its own quickstart blocks and reading the setting back from the client each route installed (EXP-034, docs/measurements/2026-09-12-client-channel-contract-qualification.json): macOS route 10/10 from an isolated HOME, native Windows client route 5/5, RTX 4090 native route 7/7, omp config get startup.checkUpdate = false on all three hosts, every fail-closed check still failing its outage request. Re-run verbatim from a stock clone of the tag after the cut.

The reusable piece noted here - a channel-aware update-check gate in the client itself - stays on the upstreaming intent toward can1357/oh-my-pi; this closes the product-side exposure.