acq kit update (sbx): live-validate that a force reapply refreshes a PRESENT-but-stale built-in kit #240

Context

quickstart#236 (ADR-0016) adds acq kit update and a stale-sandbox refresh. On the sbx backend, acq_backend_ensure_kits_applied normally only injects absent kits (a feature-probe). For a refresh, #236 adds ACQ_FORCE_KIT_REAPPLY=1, which makes the sbx heal path re-run sbx kit add for every built-in kit even when present, so a kit that is present but built from an older ref is actually updated.

The gap to validate

This relies on sbx kit add <name> <kit> overwriting an already-applied kit's files in place (config, playbook clone, CA cert, git-ssh-sign) rather than erroring or no-op'ing on a duplicate. That behavior is asserted by the offline stub tests but has not been validated against a live sbx (the test harness runs inside a sandbox and cannot nest). If sbx kit add refuses or skips a duplicate kit, acq kit update on sbx would rewrite provenance to current without actually refreshing the present kit's files.

Ask

• Live-validate on a sandbox-capable host: create a sandbox at an old PATTERNS_KIT_REF, bump the local pin, run acq kit update <sandbox> --yes, and confirm the on-disk kit files (e.g. ~/usai-config/opencode.jsonc GENERATED MODELS block) actually change.
• If sbx kit add does not overwrite a present kit, add an explicit remove/replace step (or a version-aware probe) to the forced-reapply path before writing provenance.

Notes

• Deterministic offline coverage exists (scripts/test-acq 9p7/9p13b); this issue is specifically the LIVE behavior of sbx kit add on a duplicate.
• msb is unaffected: it re-applies all kits idempotently (files overwritten) every heal.
• Fail-safe today: if the refresh doesn't actually update files, the worst case is a sandbox that still reports current while stale — no data loss, no crash.

Related: quickstart#235 (epic), quickstart#236 (PR2), ADR-0016.

AI-assisted (OpenCode); requires human review.