Detect a retargeted base at FIX entry, not only at REVIEW and MERGE

Follow-up from #68 / PR #93.

Context

#68 bound each review round to the PR, its HEAD and its base branch. REVIEW re-binds HEAD and base before launching the reviewer and marks the round stale if either moved; READY_FOR_MERGE / MERGE route base drift to REVIEW like HEAD drift.

Gap

The FIX entry (_fix_entry_problem / the HEAD check before launching the fixer) still compares the PR HEAD only. If the PR was retargeted to another base while findings are open, the fixer is launched against findings that were raised on a diff against a different base. The next REVIEW re-binds the base, so nothing unreviewed can reach MERGE, but the fix round is spent on findings that may no longer describe the PR's diff.

Proposed direction

Treat pr.base_ref != state.reviewed_base_ref at FIX entry exactly like a HEAD past the reviewed one: mark the review stale, drop the findings, FIX -> REVIEW of the actual revision without launching the fixer (_revision_drift_to_review already handles both). Skip the check when reviewed_base_ref is empty (a protocol-2 file loaded in FIX; the next review writes the binding).

Acceptance

• FIX entry with the PR retargeted → REVIEW, fixer not launched, current_base_ref updated, open_findings == [].
• FIX entry on a protocol-2 file with an empty reviewed_base_ref still launches the fixer.
• docs/agent-guides/github-safety.md "Before FIX" and README FIX row updated.

Start at _fix_entry_problem and the HEAD check before launching the fixer, then read _revision_drift_to_review and the surrounding FIX state handling. Verify the base-ref comparison is skipped when reviewed_base_ref is empty and that retargeting routes to REVIEW without launching the fixer. Update docs/agent-guides/github-safety.md under "Before FIX" and the README FIX row, then check the listed acceptance cases.