Bump the Grail pin to main as of 2026-10-15, and build unicodedata at install

[jgfoster]

Moves PINNED_GRAIL_REF from beef473 to 9fb5d23, Grail main as of today: 388 commits, 175 PRs. Grail's own CI is green on 9fb5d23. mcp_server (d836520) and GemDB Stats (v1.1.1) are already at their latest, so their pins stay.

The one installer change: build unicodedata at install

Grail's install.sh gains a step (Grail #1556). After deployGemdb.gs, it runs scripts/deployUnicodedata.gs, which builds and commits unicodedata's tables. Without that step, a session's first normalize or category call:

• takes about a second, and
• leaves the session with something to commit, which is what makes gemdb.transaction() refuse to start.

Since Grail #1512, compiling an identifier that NFKC changes (µ) also reaches it.

resources/install-grail.sh now mirrors it as step 4. A failure only warns, as upstream's does: Python still works, only slower on first use.

A new test in grail.test.ts pins this. Measured both ways: without the step it fails (needs_commit() is True after the first normalize, 1.2 s), and with it the test passes. Changing install-grail.sh also changes the install record, so an update reinstalls Grail, which a new pin needs anyway.

Installer compatibility otherwise

• Scripts: every other script install-grail.sh drives is byte-identical, and the REQUIRED list is all present.
• install.gs: additions only. Three runtime inputs (GrailCommitCoordinator, JSONDecoder, PythonTokenizerIdentifiers) plus test classes, all under src/.
• C shim: the source changed, so every platform rebuilds it. The Makefile and the GCI calls are unchanged, and the only new includes are libc's.
• What GemDB calls: the gemdb Python package is byte-identical, and every Smalltalk selector GemDB sends is still defined on the same class.
• Moves and deletions: stdlib click and requests move to _grail_click and _grail_requests (#1634), and importlib/metadata.py gives way to CPython's package (#1664). GemDB references none of them.

Behaviour changes a user can meet

• import click or import requests with neither pip-installed is now ModuleNotFoundError. Flask still works.
• vars(obj) is a live view, so writing through it changes, and commits, the object.
• Calls CPython refuses now raise TypeError: extra lambda arguments, or an argument given twice.
• An exception in a decorator propagates instead of leaving the function undecorated.
• date == datetime is False, and ordering a date against a datetime raises.
• µ and μ are the same name.

Not verified: a database carried over from 1.6.0

Neither of these was exercised here:

• Committed datetimes. PyDateTime changes superclass, so a datetime committed under the old pin remains an instance of the old class object.
• Deployed Flask. A database that deployed Flask (Brain Freeze) committed click from a path that no longer exists. Grail's runtime-generation bump should discard that registry.

Both are worth checking on a real 1.6.0 database with Brain Freeze before release.

Verified locally

On arm64.Darwin against 4.0.0.a4:

• bundle:grail: 1327 referenced files, all present
• bundle:mcp, bundle:stats, test:extent
• npm test: 948 passed
• test:integration: 12 files, 141 passed, plus the existing expected-fail and todo in debugConsole.test.ts
• package.sh: passed check-vsix.sh
• After adding the install step: grail.test.ts, 14 passed

The full write-up is in the vendor-pins.sh comment. The changelog entry goes in the release PR, as for previous bumps.

🤖 Generated with Claude Code