docs(storage): fix the schema-version changelog blocks (#2693)

Two problems, one mine and one not.

MINE: the `INCREMENTAL_SCHEMA_VERSION` block is ASCENDING (v2 … v15), and I
inserted v16 above v15 rather than at the end — I had just moved the parse-cache
entry to the top of ITS block, which is descending, and applied the same habit
to a list ordered the other way. Moved to the end; both blocks are now
internally consistent.

NOT MINE: the parse-cache block carries TWO v21 entries, with v20 wedged between
them. Tracing it: #2632 (Spring DI facts) bumped 20 -> 21 and merged first;
#2653 (Java JLS local-class identities) had branched at 20, also bumped to 21,
and merged second — so it shipped with NO invalidation of its own. An index
already stamped 21 by the first change was treated as current by the second and
kept serving stale local-class identities from the warm cache.

Numbers left alone: both genuinely shipped as 21, and renumbering them now would
misstate what users' indexes actually contain. Instead the entry says so
explicitly, and points at the process fix — re-check the constant against
origin/main immediately before merging, not just when the branch is cut. The
identical collision hit INCREMENTAL_SCHEMA_VERSION in #2653/#2654, so this is a
recurring failure mode of concurrent PRs, not a one-off typo.

Comment-only; no constant changes value.

gitnexus/src/storage/parse-cache.ts

@@ -61,13 +61,22 @@ import type { ParseWorkerResult } from '../core/ingestion/workers/parse-worker.j
 // instead of a `Function` plus an edgeless `Const` twin (#2687). Cached worker
 // results are replayed verbatim — including across `--force` — so without this
 // bump a warm cache keeps serving the old two-node set.
-// v21: Java/Kotlin Spring DI facts persist constructor, field/property, and
-// method injection sites plus bean-name and @Primary provider metadata.
+// v21: TWO changes share this number — a collision, not a typo. #2632
+// (Java/Kotlin Spring DI facts: constructor, field/property and method
+// injection sites plus bean-name and @Primary provider metadata) bumped 20 -> 21
+// and merged first; #2653 (Java local class/enum/record/interface captures using
+// javac-compatible, source-type-relative JLS 13.1 identities and
+// declaration-to-block scopes, #2562) had branched at 20, bumped to 21 as well,
+// and merged second — so it shipped with NO invalidation of its own. An index
+// already stamped 21 by the first change was treated as current by the second
+// and kept serving stale local-class identities from the warm cache. Harmless
+// now (anything below the current value is rejected), and left as-is because
+// both genuinely shipped as 21 — renumbering would misstate history. Read this
+// as the reason to re-check SCHEMA_BUMP against origin/main immediately before
+// merging, not just when the branch is cut; the same collision hit
+// INCREMENTAL_SCHEMA_VERSION in #2653/#2654.
 // v20: Java/Kotlin capture side-channels persist package and class-annotation
 // facts for shared Spring Bean resolution.
-// v21: Java local class/enum/record/interface captures use javac-compatible,
-// source-type-relative JLS 13.1 identities and declaration-to-block scopes
-// (#2562).
 // v19: Java enum constant bodies emit E$N Class nodes; anonymous naming uses
 // JLS 13.1 immediate-host chains (#2555).
 // v18: Worker$N anonymous bodies. v17: callable-value-flow operand identity.

gitnexus/src/storage/repo-manager.ts

@@ -467,17 +467,16 @@ export interface RepoMeta {
  * instance owner is outside the caller's enclosing class/MRO (#2563). The
  * incremental write set would otherwise retain those stale CALLS edges on
  * every unchanged C# and Kotlin file; force a full re-analyze instead.
- * v16: calls through a closure-valued binding (`val f = { }; f()`) now resolve
- * in Kotlin, Swift and Dart (#2693). These are NEW `CALLS` edges, and Dart also
- * gains `Function` nodes for function-local closures. The incremental write set
- * only covers changed files, so unchanged files would keep reporting a zero
- * blast radius for those symbols; force a full re-analyze instead.
- *
  * v15: `const X = <arrow | function-expression>` no longer emits an edgeless
  * `Const:<file>:X` twin beside its `Function` node (#2687). The incremental
  * write set only covers changed files, so every unchanged TS/JS file would
  * keep its twin and `impact`/`context` would stay ambiguous on those names;
  * force a full re-analyze instead.
+ * v16: calls through a closure-valued binding (`val f = { }; f()`) now resolve
+ * in Kotlin, Swift and Dart (#2693). These are NEW `CALLS` edges, and Dart also
+ * gains `Function` nodes for function-local closures. The incremental write set
+ * only covers changed files, so unchanged files would keep reporting a zero
+ * blast radius for those symbols; force a full re-analyze instead.
  */
 export const INCREMENTAL_SCHEMA_VERSION = 16;