fix(cycle): case-insensitive page-atom identity hash

[Masashi-Ono0611]

What

atomSlug's identity hash for page-derived atoms now hashes title.toLowerCase() instead of the raw title, and resolvePageAtomSlug gained a third fallback so an atom already minted under the old (un-lowercased) hash is adopted on re-extraction rather than duplicated.

Fixes #5030.

Why

extract_atoms mints a new atom identity — a duplicate — when the model's title for the same underlying claim differs only in letter case between extractions, because the identity hash for page-derived atoms was computed over the raw title. Full report, reproduction, and the maintainer's separate confirmation this is a distinct defect from the atom-retirement product question in #4908: #5030.

How

• atomSlug() (src/core/cycle/extract-atoms.ts): page-derived branch (sourcePageSlug !== undefined) now hashes title.toLowerCase(). Transcript atoms and atomSlugStem (the human-readable slug prefix) are unchanged.
• resolvePageAtomSlug(): added a third fallback after the exact new-shape and exact pre-fix(extract-atoms): prevent deterministic slug collisions from corrupting provenance #4733 legacy-shape checks both miss — search this source page's live atoms (frontmatter->>'source_slug' = sourcePageSlug, exact match only) and, if exactly one has a matching lowercased title, adopt its slug. Ambiguous (2+) matches fall through to minting a fresh slug rather than guessing.
• Title comparison happens in application code with JavaScript .toLowerCase(), not SQL LOWER() — the two disagree for some non-ASCII titles (e.g. Greek "ΟΣ" lowercases to "οσ" in PostgreSQL/PGLite but "ος" in JS), which would silently miss an adoption if pushed into SQL.
• Deliberately narrower than the legacy-slug path's isCompatibleAtomBinding rule: this fallback finds candidates by title search rather than a deterministic address, so it must not also adopt unbound (pre-binding-era) atoms from elsewhere in the source — only exact same-page bindings qualify. (An earlier version of this PR used isCompatibleAtomBinding directly and was flagged in review for exactly this over-reach; narrowed before submission.)
• No deletion, merge, or retagging of any existing duplicate pair already live in a brain. In the common case (exactly one pre-existing case-variant atom on the page, and neither exact-slug check above finds it), re-extraction now converges onto it instead of minting a new one. If both exact-slug checks miss and the same-page title search finds 2+ case-variant atoms, the fallback deliberately does not guess between them and mints a fresh slug — existing duplicates are not merged or removed.
• scripts/module-size-limits.tsv: ceiling raised for extract-atoms.ts (+77 lines) with a note.

Discrimination test

bash scripts/check-test-discriminates.sh test/extract-atoms-provenance-links.test.ts src/core/cycle/extract-atoms.ts:

Discrimination test: reverted src/core/cycle/extract-atoms.ts to merge-base, ran test/extract-atoms-provenance-links.test.ts → 12 pass / 11 fail. Restored → all pass.

Seven new test scenarios (in describe('case-insensitive atom identity (#4908)', ...)): core case-variance dedup, old-hash adoption with identical title case, old-hash adoption with different title case, ambiguous-candidates fallback (no guessing), distinct titles sharing a truncated 60-char stem staying on distinct slugs, an unbound atom with a matching title NOT being adopted, and a non-ASCII (Greek) case-variance scenario exercising the JS-vs-SQL lowercasing difference. Three pre-existing tests in the same file's #4733 describe block computed their expected slug inline with the pre-fix (non-lowercased) hash formula and were updated to track the new formula; all 23 tests in the file pass.

Scope check

• bun run typecheck: clean.
• bash scripts/check-module-size.sh: OK.
• No new CLI surface, no new config, no new doctor check, no migration.

[Masashi-Ono0611]

Applied to my live install (production brain, tier-configured, real data — not a test fixture).

Deployment method: exported this patch as a content-addressed overlay from a local patch-stack branch built on this PR's exact head (b7d51e7d1), transferred it, and applied it. Post-apply verification (gbrain-patches-verify.py) confirms the live tree is byte-for-byte identical to the exported tip across all 53 tracked files (SHA-256 per file):

mode: APPLIED — exact final-tree verification
base=43597b19e50a3abf56409337f248f7966860293c tip=dbc369a018b295916afdab31e10e7b13e1c81095
commits=15 files=53
RESULT: exact match — live tree equals the exported patch-stack tip

Post-deploy health check (gbrain doctor --fast, $0, no LLM calls):

Overall health score: 95/100. All checks OK (some warnings).

(The one WARN is connection: Skipping DB checks (--fast mode), expected for --fast and unrelated to this change.)

Smoke test:

gbrain 0.48.5.0
[conversation-parser] 19 built-in patterns

I did not trigger a live extract_atoms re-extraction against production data for this comment (that requires an LLM call and I didn't want to spend one just for this verification round) — the behavioral evidence is the unit test suite in this PR (23 tests, including the 7 scenarios specific to this fix, all passing against the exact code now deployed here) plus the discrimination test showing the fix is necessary (12 pass / 11 fail without it).