AppView does not ingest pull status records #2

AppView appears to ignore valid sh.tangled.repo.pull.status records, so pull state can diverge between ATProto/PDS clients and the official web UI.

Reproduction from onev.cat/tang while testing a CLI client:

1. Create and merge a pull request through the Tangled knot merge endpoint.

2. Write a valid pull status record:

   at://did:plc:kl2ejrmz5zmxnno3ll4luz76/sh.tangled.repo.pull.status/3mkuuaumwkn2j
   pull:   at://did:plc:kl2ejrmz5zmxnno3ll4luz76/sh.tangled.repo.pull/3mkuuamwfj322
   status: sh.tangled.repo.pull.status.merged
   

3. Query the user's PDS directly: the status record exists and matches the lexicon.

4. Query via the CLI, which follows backlinks and reads PDS records: the pull is merged.

5. Open AppView:

   https://tangled.org/onev.cat/tang/pulls/2/round/0
   

   The page still shows the pull as open.

From reading current core code, AppView's Jetstream subscription/ingester handles sh.tangled.repo.pull but does not appear to subscribe to or ingest sh.tangled.repo.pull.status. Web UI close/reopen/merge paths update AppView's local pulls.state database field directly, so AppView-local actions work, but ATProto-backed status records written by other clients do not affect the official AppView state.

Expected behavior:

• AppView should ingest sh.tangled.repo.pull.status records and derive pulls.state from the latest status record for each pull.
• Ideally, Web UI close/reopen/merge should also write the corresponding status record, or there should be a clearly documented canonical source of truth for pull state.

Related context:

• #462 covers missing AppView ingestion for sh.tangled.repo records and mentions issue state records.
• #356 discusses off-protocol records and notes that issue/PR state has a standard ATProto-record direction.

This affects third-party clients that correctly write Tangled pull status records to PDS but expect AppView to reflect protocol-level state.