investigate: a routine state-write drops cli_version_sha for pin_mode:sha repos (current binary) #390

Found during the fleet-orchestration validation. On cascade-example-4env (the only pin_mode:sha fleet repo), the repin commit had cli_version_sha in the manifest + SHA-pinned workflows (consistent), but the very next 'chore: update state for dev [skip ci]' commit dropped cli_version_sha while keeping the ci: wrapper - producing permanent drift (SHA-pinned workflows, manifest no longer declaring the pin).

Exhaustive investigation did NOT root-cause the drop for the current binary:

• The generated yq state-write (yq eval -i .ci.state....) provably preserves cli_version_sha (tested locally).
• The CLI re-marshal paths (orchestrate writeConfig, external writeManifest) were the fix(statewrite): preserve unmodeled config in the orchestrate and external-update state writes #372 lossy sites and are now fixed (fix(statewrite): route orchestrate and external state writes through WriteManifestState #389), but writeConfig preserves MODELED fields (cli_version_sha is modeled) on a current binary, so it should not drop it either.
• Yet 4env, repinned to a current binary (v0.6.0-dryrun.4, which models cli_version_sha), dropped it.

Workaround applied: the fleet repin no longer SHA-pins the example repos (they are tag-pinned, drift-free). cascade's own repo keeps its static SHA-pin (the 5 alerts stay fixed), and #389 hardens the CLI state-writes. But the exact mechanism that drops a modeled field on a current binary is unexplained and should be reproduced (run 'cascade orchestrate setup' on a pin_mode:sha + cli_version_sha manifest and observe) and fixed, since it would affect a real adopter who SHA-pins.