fix: affected-alert remediation (private fork) never produces a fork — doesn't remediate

Problem

The affected-alert path (create advisory → private fork → clone → Claude-fix in the fork) doesn't work. create_advisory_and_fork frequently returns an empty fork name (the polling loop never finds the private fork), so the clone step got https://github.com/.git/ and hard-failed. That failure was the source of the re-investigation loop on mozilla/fxa.

The loop itself is now mitigated (#129/#130 tag on failure; empty fork routes to advisory_only), but affected alerts still get zero remediation — the path just fails cleanly instead of looping.

Root question

Why is the private fork empty? Candidates: advisory fork creation is async and the poll window/field path is wrong, or a permissions gap on repository-advisories.

Proposal

Two options:

1. Fix fork detection/polling so the private-fork flow actually completes.
2. Simpler + more robust: for affected alerts, open a normal bump PR on the main repo (same mechanism as transitive bumps) and only use the private-fork + Claude-fix flow when the fix genuinely needs code changes beyond a version bump. Most 'affected' transitive advisories are still resolved by bumping the dependency, so the fork dance is overkill for them.

Impact

Enables real remediation of affected alerts (currently none).

Start at create_advisory_and_fork and trace the affected-alert path through fork polling, cloning, and the advisory_only fallback. Compare it with the existing transitive-bump mechanism and determine whether affected alerts should use that path or reliable private-fork detection. Done means affected alerts produce real remediation instead of an empty fork or clean failure.