Feat: fixer tracks its PR to conclusion and rebases when behind

[rubambiza]

Part of #72 (v0.1.1 hardening). Blocked by Phase 1 (input model).

Closes #27 — this is the RepoMan resolution of the rebase-capability request there. A PR implementing this issue should close both.

Problem

When the link-health fixer opens a PR, it currently opens and forgets. Most of these PRs target internal-facing documentation. Over time a fork-based PR falls behind upstream main and cannot merge without a rebase, and nobody is watching. (Original symptom: #27, where an approved PR needed a manual rebase before it could merge.)

Desired behavior

The fixer tracks each PR it opens through to conclusion:

• Detect when its fork-based PR is behind upstream main and rebase as needed.
• The rebase should be clean the large majority of the time.
• When a clean rebase is not possible, escalate to a human rather than leaving the PR stuck: a comment on the PR, a Slack message, or an equivalent signal.
• Keep track of open PRs and update state on merge (from feature: add rebase capability for link health fixer #27's proposed solution).

Notes

This is fixer behavior and depends on the {owner, name} input model landing first (fork/upstream identity per repo), so it is blocked by Phase 1. It stays open until v0.1.0 ships. Related to the branch-hygiene item (#80), but distinct: that one is about the local clone state before sync; this one is about the remote PR's lifecycle after it is opened.

Assisted-By: Claude Code