WatchedInfoItem: succession monitoring — watch previous primaries via include_deactivated API

[gregoryfoster]

Context

Descoped from CannObserv/archiver#44 (now closed). The Archiver side shipped in archiver v3.6.0 (2026-05-29):

• `GET /api/v1/info-items/{id}?include_deactivated=true` returns deactivated `InfoItemSource` bindings (previous primaries) annotated with `is_active: false` and `deactivated_at`.
• New `info_item_primary_changed` bus event on `info.changes` carries `old_info_source_id` / `new_info_source_id` whenever a NULL-role binding is created. `old_info_source_id` is `null` on first assignment.
• SDK 3.3.0: `get_info_item(include_deactivated=True)`, `deactivate_info_source_binding(info_item_id, info_source_id)`.

The gap

`WatchedInfoItem` currently models one URL per item (the current primary). After URL succession, Watcher has no mechanism to continue watching the previous primary URL — exactly the scenario where an unexpected content change on a retired-but-still-accessible URL should be surfaced.

Work

• Subscribe to `info_item_primary_changed` — on receipt, start a Watch for the new primary's InfoSource; optionally retain the Watch for the old primary (operator-controlled; no auto-teardown).
• InfoSource discovery sweep — validate that Watcher's existing mechanism for discovering new InfoSources bound to an InfoItem (sub_aspects, cross_checks) also picks up deactivated NULL-role bindings when `include_deactivated=true` is used. Extend if needed.
• `WatchedInfoItem` model — extend to support watching previous primaries alongside the current one (if the model currently assumes a single URL per item tick).
• Retention policy — confirm operator-controlled Watch deactivation is sufficient (no automatic teardown on primary replacement). Document in AGENTS.md.

What does NOT change

• Archiver DB constraint (one active primary per InfoItem) is unchanged.
• Fetch group invariant (one URL fetched per tick for the current primary) remains valid.
• Fragment bindings (`cross_check`, `sub_aspect`) do not auto-transfer when a primary is replaced — they remain anchored to the InfoSource they were bound against.

References

• Design: "current" vs "previous" primary InfoSource — vocabulary, API exposure, and Watcher succession monitoring archiver#44 (closed — Archiver portion complete)
• archiver CHANGELOG v3.6.0
• `src.core.changes.payloads.InfoItemPrimaryChangedEvent` in the Archiver repo