v1.90.2.0 perf: halve local free-suite time and preserve coverage (#2972)

* perf: remove repeated test work and preserve AUQ execution budgets

* fix: validate native evaluation fixture evidence at its actual boundaries

* fix: clarify deployment approval and recovery state transitions

* chore: document coverage and release v1.90.2.0

* test: preserve Windows scheduling and native no-change consent

* test: recognize verified reads through fixture symlinks

* test: isolate alias-name installation from runtime assets

CLAUDE.md

@@ -514,30 +514,24 @@ package.json (npm rejects it). Rationale and translation rules live in the
 `lib/version-source.ts` header; `test/gstack-version-bump.test.ts` pins the
 contract.
 
-**Scale-aware bumps — use common sense.** When the diff is big, bump MINOR (or
-MAJOR), not PATCH. PATCH is for bug fixes and small additions; MINOR is for
-substantial new capability or substantial reduction; MAJOR is for breaking
-changes. Rough guideposts (don't treat as rules, treat as smell-checks):
+**Choose versions autonomously; default to PATCH.** Garry delegates release
+version decisions to the agent. Do not ask him to choose or approve a version,
+including when an already-approved version collides with another PR. This policy
+overrides generic version-approval prompts in `/ship` and `/document-release`.
 
-- **PATCH (X.Y.Z+1.0)**: bug fix, doc tweak, small additive change, single
-  test/file added. Net diff under ~500 lines, no new user-facing capability.
-- **MINOR (X.Y+1.0.0)**: new capability shipped (skill, harness, command, big
-  refactor), substantial code reduction (compression, migration), or coordinated
-  multi-file change. Net diff over ~2000 lines added/removed, OR a user-visible
-  feature you'd put in a tweet.
-- **MAJOR (X+1.0.0.0)**: breaking change to public surface (CLI flag rename,
-  skill removed, config format changed), OR a release big enough to be the
-  headline of a blog post.
+Prefer **PATCH (X.Y.Z+1.0)** for ordinary releases, including fixes, additions,
+refactors, test infrastructure and coordinated multi-file work. Diff size alone
+is not a reason to choose MINOR. Choose **MINOR (X.Y+1.0.0)** or **MAJOR
+(X+1.0.0.0)** only when calling the release a patch would be plainly misleading
+("ridiculous"), such as an incompatible public-interface change or a genuinely
+new product-scale release. Make that judgment without another approval question.
 
-If you find yourself debating "is 10K added + 24K removed really a PATCH?" — it
-isn't. Bump MINOR. Same for "this adds a whole new test harness with 6 new E2E
-tests + helper utilities" — MINOR. The bump level is communication to the user
-about what kind of release this is; don't undersell it.
-
-When merging origin/main brings a higher VERSION, re-evaluate the bump level
-against the SCALE of your branch's work, not just whether main moved forward.
-If main bumped MINOR and your branch is also a substantial change, you bump
-MINOR again on top (e.g., main at v1.14.0.0, your branch lands v1.15.0.0).
+Use `bin/gstack-next-version` to check the live release queue before publishing.
+If a slot is claimed, advance to the next available version at the chosen bump
+level and use `bin/gstack-version-bump` to synchronize release metadata. A higher
+base version does not itself require a MINOR bump. Keep the PR ready for Garry to
+merge; autonomous version decisions do not authorize merging, deploying or
+skipping required validation.
 
 **VERSION and CHANGELOG are branch-scoped.** Every feature branch that ships gets its
 own version bump and CHANGELOG entry. The entry describes what THIS branch adds —