refactor(rust): separate program and draft workspace ownership

[TusanHomichi]

Evidence

The 2026-09-05 continuation audit (PR #55, head 3d87379) found two large Rust owners:

• crates/consolebook-server/src/programs.rs: 1,527 lines. Configuration vocabulary starts at VersionContent (line 33), validation at line 313, service operations at line 565, and persistence helpers at line 934.
• crates/consolebook-server/src/evaluation_drafts.rs: 1,021 lines. Workflow operations include create, transfer, and submit; workspace response types start at line 656 and workspace at line 762.

These are maintainability findings, not demonstrated runtime failures. CONTRIBUTING.md requires an ownership-based reorganization when adding behavior beyond 1,000 lines, and naming the boundary before behavior changes beyond 1,500 lines. No existing open or closed issue owns this decomposition.

Proposed ownership and scope

• Give program vocabulary/validation and persistence helpers focused owners beneath the programs domain; retain policy/transaction orchestration in the service owner and compatible public re-exports where necessary.
• Separate draft workspace projection and its response types from draft workflow transitions. Preserve shared record-loading/event helpers as explicit domain-owned interfaces, not a generic utilities bucket.
• Record the agreed move/new-owner/public-and-persisted-impact plan in the implementation PR before broad edits. These boundaries are proposals, not an already-reviewed decomposition plan.
• Coordinate the programs changes with Write transactions: deferred snapshots can surface SQLITE_BUSY_SNAPSHOT as 500s under concurrent writes #27 and the draft workspace changes with Draft workspace: keep the losing writer's text visible after a stale-save reload #34 to avoid overlapping refactors. This issue can be delivered as linked focused slices; leave it open until both owners are handled.

Acceptance criteria and proof

• Both named modules have focused ownership boundaries; splitting by arbitrary line counts is insufficient.
• Preserve public service/refusal behavior, authorization and transaction boundaries, serialization, schema, and canonical/export bytes. No migration or feature behavior change is part of this refactor.
• Prove programs/programs_api/enrollments and evaluation_drafts/draft_review integration suites, plus export/finalization suites affected by moved types.
• Run all CONTRIBUTING.md gates, including the program/draft browser scenarios, and update docs/development.md for moved source ownership.

Refs #53, #55. Source: docs/audits/2026-09-05.md, “Large owners need scoped decomposition.” Prioritize when these owners next change; this does not block merging the audit.

[TusanHomichi]

The programs ownership slice is complete in PR #63, merged at 6515808 as part of #27's transaction retrofit.

• programs/content.rs owns configuration vocabulary and structural validation.
• programs/persistence.rs owns content persistence and caller-transaction insert helpers.
• programs.rs retains policy, typed refusals, summaries, and transaction orchestration, with compatible public/crate re-exports.

The move/owner/impact/proof plan was recorded in the draft PR before broad edits. Extracted bodies match the prior main apart from formatting and sibling visibility; there is no schema, serialization, canonical-byte, or public signature change from the extraction. The accompanying #27 behavior change reserves write transactions before validation and awaits refusal rollback, documented in ADR 0019.

Validation at PR head b1e8d45484108cf8faa730b4c8e211899d3903b5: all repository gates passed, 155 Rust tests (including programs/programs_api, enrollment, draft/review, finalization, and exports), 8 browser scenarios, and green CI.

This issue remains open for evaluation_drafts.rs workspace projection and response-type ownership, coordinated with #34. That owner was not changed by #63.