feat(dict): make the build's dictionary version deploy-authoritative

The dictionary lives on a persistent volume seeded from the image once and never
re-seeded, so a redeploy that bumped BACKEND_DICT_VERSION left the new DAWGs
unreachable (the volume mount shadows the image copy) and the active version stuck
at whatever the admin console last installed — a native offline-first client then
fetched the server's older pinned version over the network instead of using its
bundled dict.

On boot the backend now DELIVERS the build version onto the volume add-only, from a
second unshadowed image copy at BACKEND_DICT_SEED_DIR, into DICT_DIR/<version>/ when
absent (the flat seed and prior uploads untouched, so in-flight games keep theirs),
and InitActiveVersion makes the build version active — except a console-installed
version NEWER than the build (compared numerically) is not downgraded by a restart.
The .seed_version guard still protects the flat seed's label (a bump is a new
subdirectory, never a relabel). The console stays for out-of-band updates.

Docs: ARCHITECTURE.md §5, deploy/README.md, seedmarker.go. Tests: engine.DeliverVersion
(add-only, idempotent, flat-seed skip), compareDictVersions, and the dictionary-update
integration test's deploy-delivers path.

backend/internal/engine/seedmarker.go

@@ -25,11 +25,11 @@ const seedMarkerFile = ".seed_version"
 //     BACKEND_DICT_VERSION) and return it — the seed of a fresh volume;
 //   - already-seeded directory: return the recorded marker and ignore bootVersion.
 //
-// So bumping the build seed on a live volume is a harmless no-op (it only takes
-// effect on a future fresh volume) instead of relabelling the already-seeded bytes —
-// which would void games pinned to the prior label and mis-serve new ones. New games
-// still pin the active version (DB-persisted, set by the admin console), which is the
-// real way a running contour moves to a new release.
+// So a later build seed never relabels the already-seeded flat bytes — which would void
+// games pinned to the prior label and mis-serve new ones. The new build version is instead
+// delivered as a NEW subdirectory (DeliverVersion) and made active (Service.InitActiveVersion),
+// so a redeploy still moves new games to it while old games keep the flat label. New games
+// pin the active version (DB-persisted); a console upload can also set it out-of-band.
 //
 // A directory that cannot be written makes the first record fail; that also breaks
 // the admin console (which writes version subdirectories here), so the error is