Wire the output project (back-translation / adaptation) into export, not creation

Follow-up to #94 — resolving the second and third model gaps (interlinearMode and the targetProjectId semantic question): model the interlinear output (a back-translation project or an adaptation/daughter project, PT9 Options 3 & 4) as a deferred, attach-when-you-export concern — not a mode chosen at project creation.

Design principles this follows

• Simplify project creation — you don't declare "this is a back-translation project" up front. A project starts as just gloss a source; an output target is chosen later, only if and when you produce output.
• Generalize the interlinearizer — a project isn't locked to one output kind or destination. An output target is attached, changed, or dropped at will, and the same analysis can serve gloss-only use or feed an export.
• First-contact discoverable — the output picker and its intent (BT vs adaptation) surface intuitively at export time, and aren't worried about before then.

Reframe

#94's original framing made the output a creation-time mode (PT9 Option 3 = back translation, Option 4 = adaptation/revision), each locking the project into producing a second project. This issue defers that:

• The output target (a second Platform.Bible project glosses/adapted text are written to) is attached at export time via the project metadata modal, not at creation.
• An output-intent discriminator distinguishes back-translation from adaptation, driving export behavior and UI wording — set alongside the output target, when it's chosen.
• No creation-time mode picker.

Model additions

• InterlinearProject.interlinearMode?: 'back-translation' | 'adaptation' (the #94 gap #2 proposal). Absent for gloss-only projects (PT9 Options 1 & 2) and for BT-Extension alignment imports; present only when the analysis is being exported to an output project. Consider naming it outputMode to reflect the reframe — see Open questions.
• Resolve the targetProjectId overload (#94 gap #3). targetProjectId currently means "alignment target for a BT-Extension import" — an input whose AlignmentLink.targetEndpoints resolve to a second text (InterlinearProject.targetProjectId). The PT9 output project plays a structurally similar role (a second project + cross-side links) but the relationship is one-directional export, not two-way alignment. Recommendation: reuse targetProjectId for the output destination and let interlinearMode carry the intent that disambiguates the two uses. Update the field's JSDoc to document both meanings — including src/types/interlinearizer.d.ts:291, which currently documents targetProjectId as "absent for analysis-only projects (LCM, PT9)"; reuse makes it present on an imported PT9 project that has an export target.

The distinct cases the model must represent:

Where this gets consumed

• Export/output feature (largely future work) reads targetProjectId + interlinearMode to decide what to write and where. This issue is about modeling the output so it's deferred and attach-later; the actual write-back to the output project can be built on top.
• UI wording keys off interlinearMode (e.g. "Export back translation" vs "Update adaptation").
• The metadata modal / interlinearizer.updateProjectMetadata already accept targetProjectId?; add interlinearMode? there (and mirror on DraftProject as targetProjectId is mirrored, so it survives Save As).

Companion issue

The model-text suggestion source is the sibling gap, tracked in #148: it defers the suggestion input the same way this defers the output. PT9 import shipped in #150; attaching an imported project's output/BT project is #215, which consumes this issue.

Out of scope

• Building the actual export/write-back pipeline to the output project (separate feature work).
• Model-text suggestions (companion issue #148).
• Any project-creation UI changes.

Open questions

• Field name: keep interlinearMode (traceable to #94) or rename to outputMode (clearer under the reframe)?
• Reuse vs. separate field: reuse targetProjectId for both alignment-import and export-output (recommended, disambiguated by interlinearMode), or add a dedicated outputProjectId to keep the two roles physically separate?
• Should this go to user-questions.md for review outside the dev team, given it decides project-output UX? (per AGENTS.md UX-decisions guidance)

Size: S–M (model fields + metadata-modal wiring; the export pipeline itself is separate)
Priority: P2 — unblocks a coherent output/export design; not blocking gloss-only use

Read src/types/interlinearizer.d.ts, especially the targetProjectId documentation at line 291, then trace updateProjectMetadata, the metadata modal, and DraftProject. Resolve the field naming and targetProjectId reuse questions, wire optional interlinearMode through metadata updates and Save As, and ensure the model documents both alignment and export meanings without changing project creation or implementing write-back.