Screen OSF registrations on their registration content, not the stored abstract

**The screen cannot see what an OSF registration says.** The expensive screen reads the stored abstract. For a registration on the `10.17605` registrant, that abstract is often the registration template rather than a description of a study, so the screen cannot assign a record type. Those rows ship with an empty `type` and never become validation-ready.

Stage 3 already acquires the registration form — the `osf_registration` source in `shared/pdf_sources.py` pulls it from the OSF API. Stage 2's screen never sees that content.

**Concrete defect to cover.** `10.17605/osf.io/zya9n` ("Mere ownership replications extension") is a preregistration reporting no results. Its 3 rows in `data/extracted.csv` carry outcomes (`successful`, `failed`, `successful`) coded off registration text that describes planned and prior work. Those outcomes are wrong. The rows stay untyped, so they are never imported to validation — but the coding path should refuse to code an outcome from a registration that reports no results, rather than depend on the missing `type` to hold it back.

**Ask:**

1. Feed registration content to the screen, or give registrations their own screen.
2. Guard outcome coding for results-free registrations.

Trace Stage 3's osf_registration source in shared/pdf_sources.py and the Stage 2 screen to determine where registration content is available and where the stored abstract is used. Reproduce the zya9n rows in data/extracted.csv, then verify that results-free registration text cannot produce outcomes and that valid records receive the intended type before validation import.

Written by the indexing model from the issue text.