use mortie's flat toc constants after the 0.9.10 submodule retirement (issue #493)

[espg]

Closes #493.

mortie 0.9.10 retired the mortie.toc submodule (espg/mortie#199, following #197 for mortie.moc): the name is now the Toc constructor, and its migration shim covers attribute access only — a callable cannot also be a module, so statement-form from mortie.toc import X raises ModuleNotFoundError. mortie's CHANGELOG states this as a break rather than a deprecation.

zagg carried three such imports. One is runtime source, so this is not a test-only problem: zagg.time_axis's toc encode path would raise on any environment with 0.9.10 installed.

file:line	scope	effect under 0.9.10
src/zagg/time_axis.py:329	runtime (function-local, toc encode path)	ModuleNotFoundError at encode
tests/test_time_axis.py:12	module level	whole suite fails at collection
tests/test_time_axis.py:343	function-local	test error

The change

All three move to the flat top-level spelling, which is the supported one:

from mortie import TOC_MAX_NS            # was: from mortie.toc import TOC_MAX_NS
from mortie import Q_END_NS, Q_START_NS  # was: from mortie.toc import Q_END_NS, Q_START_NS

Plus one stale docstring in src/zagg/time_axis.py that pointed readers at mortie.toc as the module owning word semantics; it now names the flat kernels and notes what mortie.toc became.

The floor bump — please confirm

mortie>=0.9.9 → mortie>=0.9.10, and this is not optional cosmetics: Q_START_NS / Q_END_NS / TOC_MAX_NS are not top-level names in 0.9.9. Verified against both releases, so the import style and the floor are one change, not two — on 0.9.9 the new spelling would fail exactly as the old one fails on 0.9.10.

Verified against a clean mortie==0.9.10 install in an isolated venv:

installed: 0.9.10
flat import OK: 2147483648 4294967296 9223372032559808512
OLD statement-form import correctly fails: ModuleNotFoundError

Flagging it explicitly under §4 since a dependency-floor change is the maintainer's call — but note the floor is already effectively forced: CI resolves mortie unpinned, so it installs 0.9.10 today regardless of what the manifest says. The manifest is currently the thing that is wrong, not the thing holding the line. zagg also wants 0.9.10 independently for the Moc/Toc objects the moczarr reader path now uses.

How it was tested

• The break and the fix both reproduced against a clean mortie==0.9.10 venv (output above).
• ruff check and ruff format --check clean on both touched files.
• Full-suite verification is deferred to CI: this checkout's venv still has mortie 0.9.9 installed, and upgrading it would disturb an environment in active use. CI installs unpinned mortie, so it exercises exactly the 0.9.10 path this fixes.

Questions for review

1. The floor bump above — confirm >=0.9.10.
2. Discovered while verifying demo PR demo: 07_minimal on the clean moczarr/mortie Moc/Toc API (issue #328) #492; this currently breaks every open zagg PR whose CI runs after 0.9.10 published (14:31 UTC today). PR small fixes 2026-08-19: sweep nudge for a dropped §10 section; the walk-as-tightener refresh contract #491 shows green only because its last run predates the release. Recommend merging this ahead of the other open PRs so their CI reflects their own changes rather than this.
3. Left deliberately out of scope: a repo-wide audit for other mortie submodule imports found none beyond these three (mortie.moc has no statement-form importers; remaining mortie.toc* hits are flat kernel calls like mortie.toc2time / mortie.toc_overlaps, which are unaffected).

[espg]

🤖 from Claude

CI is green on the fix — test (3.12), test (3.13), ruff, check, build/build-arm64, build/build-x86_64 all pass. That is the real proof of both halves: CI resolves mortie unpinned, so it installed 0.9.10 and the suite collected and passed, where the pre-fix code fails at collection under the same resolution.

One deployment consequence worth knowing, checked rather than assumed. deployment/aws/build_layer.sh:114 derives MORTIE_SPEC from this dependency line via tomllib (issue #322), and the layer's mortie "floats to latest-above-floor" by design. Verified the derivation against the edited manifest: it now yields mortie>=0.9.10, so the next Lambda layer build installs mortie 0.9.10.

That makes this fix a prerequisite for the next fleet deploy, not merely a CI repair:

• The currently deployed layer predates the 0.9.10 release (published today, 14:31 UTC), so the fleet is safe as it stands.
• But the moment a layer is rebuilt, workers get mortie 0.9.10 — and unfixed worker code would raise ModuleNotFoundError on zagg.time_axis's toc encode path (src/zagg/time_axis.py:329), which is exactly the path any output.time_encoding: toc run takes.

So the ordering that matters: merge this before the next layer build or fleet deploy. No change to build_layer.sh itself is needed or made — the derivation already does the right thing; this note exists so the sequencing is explicit rather than discovered during a deploy.

No deployment/aws/ file was modified (CLAUDE.md §1).