Attach the discovered model and output projects to an imported PT9 project

Scope item 7 of #150, split out so the import pipeline itself is not blocked by it.

A PT9 project records two relationships beyond its interlinear data: the model text it glosses against, and the output project (back-translation or adaptation) it writes to. Import should discover both and attach them to the resulting InterlinearProject. Everything else in #150 — the import command and UI, the cluster→token mapping, gloss-text resolution, punctuation / Excluded / Hash, keys and offsets, multi-file merge — is independent of this and produces a working, editable project without it.

Why this is separate

Both fields this issue writes are introduced by other issues:

• modelProjectId comes from #148 (model-text suggestion source)
• targetProjectId semantics and interlinearMode come from #149 (output project)

Neither exists yet, so #150 was carrying two blockers for one of its seven scope items — chaining an L issue behind another L issue (#148) for what is, once the fields exist, field population. Splitting it lets #150 start.

Note also that an imported project is useful without either link: #148 records that imported PT9 clusters land as approved TokenAnalysis glosses, which enter the existing surface-form suggestion pool from #131 immediately — "no alignment needed for the already-glossed vocabulary." The model link only covers source words the import never glossed.

Scope

• Read the PT9 project's configuration to discover its model text and its BT/daughter project. These are not in the interlinear XML — InterlinearData carries only ScrTextName, GlossLanguage, BookId, and Verses (see src/parsers/pt9/interlinearXmlParser.ts and the schema in src/parsers/pt9/pt9-xml.md). They live in PT9 project settings, so this needs a second source of truth.
• Map each discovered PT9 project to a Platform.Bible project id.
• Populate modelProjectId (#148) on the imported project.
• Populate targetProjectId + interlinearMode (#149) when the PT9 project has an output target, using #149's discriminator to distinguish back-translation from adaptation.
• Leave all three absent for a gloss-only PT9 project (Options 1 & 2) — an absent link must not be represented as an empty string.

Open questions

• Where does the configuration come from? Carried over from #150: PT9 stores the model text and BT/daughter project in project settings, not the interlinear XML. Reading it depends on how PT9 data reaches us at all (a mounted project directory, individual XML files, or a PAPI-exposed PT9 project) — which #150 also has open. That question should be answered once, there, and this issue follows it.
• What if a discovered project has no Platform.Bible counterpart? Drop the link silently, warn, or block the import? Dropping silently loses a relationship the user may not know existed.

Out of scope

• Building the model-suggestion engine (#148) or the export pipeline (#149) — this issue only attaches the links.
• Any change to the import pipeline itself (#150).

Blocked by: #148, #149. Part of: #150.

Start with issue #150 and read src/parsers/pt9/interlinearXmlParser.ts plus src/parsers/pt9/pt9-xml.md to understand the existing import inputs. Resolve how PT9 project settings reach the importer, then follow #148 and #149 for the model and output-field semantics. Done means discovered Platform.Bible counterparts populate the appropriate links and mode, while gloss-only projects leave all three fields absent.