Introduce lib/submission.ts as Submission concept owner

[ProfessorPolymorphic]

What to build

Today there is no module that owns the Submission concept. Scoring lives in lib/builder-guide-data.ts, status labels and SLA in lib/intake-config.ts, similarity input-shaping in app/api/submissions/[id]/similarity/route.ts, and the persistence (insert into submissions + denormalize into submission_details) is hand-rolled in app/api/submissions/route.ts. There is no Submission type — just a tuple of facts assembled at every callsite.

The bugs in this flow won't be in any one extracted helper — they'll be in how scoring + denormalization + status transitions + similarity get stitched together. That's the locality gap the deepening targets.

Introduce a module that owns the Submission lifecycle end-to-end:

• The Submission type (with its fields, status, score, tier)
• A factory that turns builder-guide answers into a scored Submission
• The persistence path (the two-table insert into submissions + submission_details)
• Status transitions (using the labels/SLA already in intake-config.ts)
• The call into lib/similarity.ts with the right profile shape

API routes become thin HTTP adapters. The scoring tables stay in builder-guide-data.ts (data) but are consumed via the new module.

Acceptance criteria

• lib/submission.ts exists and exports the Submission type plus the factory, persistence, and status-transition functions
• app/api/submissions/route.ts is a thin handler that delegates to the module — no inline SQL or denormalization
• app/api/submissions/[id]/similarity/route.ts gets its similarity profile from the module, not by re-shaping the row inline
• intake-config.ts and builder-guide-data.ts survive as data tables; the orchestration moves to submission.ts
• npm run build passes; manual smoke test: a submission can be created via the wizard and viewed at /intake/[token]

Blocked by

None - can start immediately