Deposit → parent linkage worklist for discarded artifacts (deferred; measure the loss first)

## What is being deferred

The Stage-2 rule book v2 proposal (`redesign/rulebook_v2.html`) discards two classes of object
that can, in a minority of cases, be the **only** record of a replication:

- **A1 `not-a-paper-doi`** — DOIs on deposit-only registrant prefixes, and DOIs ending
`.suppl`. The discard rests on the claim *"the paper is in the corpus under its own DOI, so
discarding the deposit loses nothing."*
- **A3a `no-codable-text`** — `type ∈ {dataset, software, supplementary-materials, component,
database}`. The discard rests on the claim *"even if this is the artifact of a replication,
it carries no abstract and no prose, so there is nothing to screen and nothing to code an
outcome from."*

Both claims are reasonable and both are being adopted. Neither is airtight, and the failure
mode is the same in each case: a deposit titled *"Replication Data for: X"* is discarded, and
X turns out not to be in the pool — no article DOI in OpenAlex, or an article whose title and
abstract carry no replication vocabulary and so never reach Stage 2 at all. The deposit was the
only place the word "replication" appeared, and we deleted it.

The mitigation named in the proposal is a **linkage worklist**: instead of the discard being
the end of the row, record the deposit's parent DOI, check whether the parent is present in the
survivor pool and admitted by some other route, and route the unlinked remainder to a human or
an artifact-resolution workflow.

**We are not building that now.** This issue records why, and what is owed in the meantime.

## Why it is not trivial

Deposit → parent linkage looks like a metadata lookup and is not one:

- Repository relation metadata is inconsistent and frequently absent. DataCite exposes
`relatedIdentifier` with `isSupplementTo` / `isPartOf` / `isCitedBy`, but registrants
populate it unevenly, and a large share of deposits carry no relation at all.
- Where a relation exists it may point at a preprint, a project page, a versioned sibling
deposit, or a landing-page URL rather than the article DOI.
- OpenAlex does not reliably carry the relation, so this is a CrossRef/DataCite API problem,
not a pool-column problem — i.e. it is a new metered API path with its own rate limits,
caching and failure handling, not a filter change.
- Title matching as a fallback is fuzzy in a specific nasty way: *"Replication Data for:
Failure to Generalize Spatial Effects"* and the article *"Failure to Generalize Spatial
Effects"* match well, but *"Data and code for a replication of Smith et al. (2020)"* and the
article *"Prospect theory does not travel"* share nothing.
- One deposit can accompany several papers, and one paper several deposits, so this is a
many-to-many resolution problem, not a join.
- The unpublished case has no parent by construction: a replication posted only to a repository
as a report or registered project. Linkage cannot recover those — they need a different
decision about whether an unpublished replication is a FLoRA record at all.

None of this is a reason to keep the deposits in the screening pool: an object with no abstract
still cannot be screened or outcome-coded, so admitting it buys a paid "unclear" (see #149, and
the ~70% of dataset rows that survive the screen because the model cannot discard text it
cannot read). The right shape is a separate resolution path, and that path is real work.

## What is owed in the meantime

Even without the fix, **the size of the loss must be measured** — this is V1's parent-recovery
obligation in `redesign/rulebook_v2.html` §7, and it does not depend on this issue landing:

- [ ] Sample deposits discarded by A1's prefix arm and by A3a. For each, measure the joint
probability: parent DOI resolvable × parent present in the survivor pool × parent
admitted by some non-deposit route.
- [ ] Report the residual — deposits with no recoverable admitted parent — as a count and a
rate, stratified by registrant prefix and work type.
- [ ] Record that number alongside the A1/A3a `measured` entries, with its denominator (#151).

If the residual turns out to be negligible, this issue can be closed without building anything.
If it is not, the measurement tells us which registrants and which types the worklist actually
needs to cover, which is a much better starting point than building it blind.

## Scope, if and when it is built

- Record `parent_doi`, the relation type it came from, and parent-presence status on the
discarded row rather than dropping it silently.
- Resolve via DataCite/CrossRef relation metadata first, title similarity only as a scored
fallback with a threshold, never as a silent correction.
- Route deposits with no admitted parent to `needs_human`, not to an LLM screen — there is
still no text for a model to read.
- Decide separately whether a repository-only (unpublished) replication is a FLoRA record.

## Related

- `redesign/rulebook_v2.html` §3 (A1, A3a) and §7/V1 (the parent-recovery measurement)
- #155 (reproduction routing rule — CODECHECK certificates raise the same "artifact vs record"
question)
- #146 (the filter engine), #149 (unreadable rows proceed at inflated rates), #151 (evidence
and denominators)

Start with redesign/rulebook_v2.html §7 and inspect how A1 and A3a discarded rows and the measured entries are represented. Sample both discard groups, calculate parent resolvability, survivor-pool presence, and non-deposit admission using the denominator guidance in #151, then report residual counts and rates stratified by registrant prefix and work type.

Written by the indexing model from the issue text.