Render and approve imported non-approved analyses

Import persists analyses the app cannot show. Split out of #254, which surfaced this while analyzing its Option 1 eligible set — it is a precondition for bulk approval rather than part of it, and it is what #148 and #149 are actually waiting on.

The gap

PT9 import writes 'approved' only for a verse carrying Hash, and PT9 writes the hash only for an approved verse, so a real imported project is mostly 'suggested' — plus 'candidate' where a would-be-approved record's tokens were already claimed (analysisMerger.ts:282, :379), and 'rejected' for an Excluded cluster.

Every persisted-link selector filters to approved, so none of it reaches the screen: selectApprovedIdByTokenRef (src/store/analysisSlice.ts:986), selectPhraseLinks (:1155), and the same filter at :164, :222, :299, :1195.

The suggestion dropdown already has the vocabulary — 'suggested' and 'candidate' rows with a promote affordance (SuggestionDropdown.tsx:49) — but it is fed from the engine pool, whose entries are computed on read (suggestion-engine.ts:172, :226), never from stored links. The states exist; nothing routes persisted links into them.

Promotion is broken for these records today

approveAnalysisForToken resolves the token's existing link through resolveApprovedAnalysis (analysisSlice.ts:217), which sees approved links only. For a token whose sole link is an imported 'suggested', that returns nothing and the reducer falls through to pushing a second link with status: 'approved' (:742), leaving the imported one in place. Wired to a button as-is, approval would produce two links per token and orphan the original.

Ask

• A selector surfacing persisted non-approved token and phrase links, excluding 'rejected'.
• Route them into the existing 'suggested' / 'candidate' presentation rather than inventing a second one.
• Promote by flipping the existing link's status, not by appending a link. Decide whether that is a new action or a branch in approveAnalysisForToken.
• A phrase-side path: selectPhraseLinks needs a non-approved-aware companion, since imported phrases carry the same statuses (languageAnalysisBuilder.ts:152).

Why this unblocks others

• #148 — the surface-form tier feeds on approvedCountByAnalysisId via buildPoolIndex, so an imported gloss enters the pool only once something approves it.
• #149 — export-on-approval has no approvals to fire on.
• #254 — Option 1's no-op-on-a-freshly-imported-project defect disappears once this population is visible, and its eligible set becomes a union over two visible populations rather than a question about an invisible one.

Out of scope

• Bulk approval in any form (#254).
• What confidence means on an approved link (#309).
• Re-pointing an already-approved link (#254's sharp edge, which does gate on #184).

Size: M — selectors, one reducer path, and the phrase side; no new UI vocabulary.
Priority: P1 — imported data is invisible today, and this is the smallest change that makes an imported project usable.

Start with the persisted-link selectors and approval flow in src/store/analysisSlice.ts, especially the selectors near lines 164, 222, 299, 986, 1155, and 1195 and approveAnalysisForToken near line 742. Trace how SuggestionDropdown.tsx and suggestion-engine.ts present suggested and candidate entries, then inspect languageAnalysisBuilder.ts:152 for phrase links. Done means imported non-rejected links appear in the existing presentation and promotion changes the existing link status without creating a duplicate.