Deploy-lane orphan: Express server (Phase 1 + auth + routes) has no production target

[chitcommit]

Issue

chittychronicle has two execution surfaces:

1. `worker/index.ts` — Cloudflare Worker stub deployed at `chronicle.chitty.cc`. Only mounts `/health`.
2. `server/index.ts` — Express server where the real application lives: hybrid timeline search, `requireServiceToken` middleware (just landed in PR feat(phase1): fail-closed requireServiceToken + parameterized SQL + 4 SOTA routes #44), the four Phase 1 routes (`GET /api/timeline/search/hybrid`, `POST /api/timeline/ask`, `GET /api/timeline/search/keyword`, `GET /api/timeline/search/semantic`), `semanticSearch()` with the parameterized SQL + vector(1536) schema fix, etc.

The Express server has no production deployment lane. Pre-PR #44 curl confirmed all four routes return 404 on `chronicle.chitty.cc`. So:

• Code is tested (7/7 pass, real Express + live fetch, no mocks).
• Code is reviewed + queued for auto-merge.
• Code will not actually run anywhere once merged.

Same drift class as

• chittyconnect deploy chain (#207, #216, #221 — fixed via safe-deploy + sentinel guard).
• chittymcp deploy chain (#113 — CF token scope blocker).

In all three cases the symptom is the same: PRs merge to main, code is correct, but the production lane is broken or absent, so the work is invisible to consumers until the deploy chain is sorted.

Resolution paths (operator/maintainer decision)

A. Expand the worker stub to mount the Express routes. Re-architect `worker/index.ts` to handle the four Phase 1 routes via the existing CF Worker runtime (Hyperdrive bound, vector ops via Workers AI / external embed service). Pro: keeps everything on the existing CF infrastructure. Con: rewrite + service-binding wiring.

B. Stand up a separate Express deployment (e.g. a Fly.io / Render / Cloud Run app) for `server/index.ts`. Wire `chronicle.chitty.cc` (or a subdomain) as the public face via DNS / CF Origin Rule. Pro: minimal code change. Con: new infra surface, separate auth/credential pipe.

C. Hybrid — worker fronts the Express server. Worker stub remains the public edge; proxies to the Express service over a private channel. Same trade-offs as B plus one extra hop.

What needs deciding before #44 can be useful

1. Which path (A / B / C)?
2. Token provisioning (`CHITTYCHRONICLE_SERVICE_TOKEN` — chico-keys' lane once the lane is decided).
3. Safe-deploy + binding-drift cron pattern (the chittyconnect#221 / chittyops#78 shape) — port to chittychronicle once the lane exists.

References

• chittychronicle PR feat(phase1): fail-closed requireServiceToken + parameterized SQL + 4 SOTA routes #44 (the work that surfaced this gap)
• chittyentity tasks SOT id `3db5056b-1716-4ea4-99f6-8ecd7f5d8fba` (Neon Auth Plan Action 2 — completed in SOT, even though prod is dark)
• chittyconnect#221 (sentinel guard pattern for the deploy hygiene)
• chittyentity#324, #315 (safe-deploy pattern to port)