hive-forge: precise wording on stale-branches rebase+ff ancestry claim

hive-forge/src/verbs/lint.rs

@@ -285,12 +285,12 @@ fn run_stale_branches(client: &Client, args: StaleBranchesArgs) -> Result<()> {
     // head isn't "stale", it's "in review" (skip-list, as before), and
     // a closed one tells a surviving stale branch its actual fate —
     // merged (branch is a leftover copy, safe to delete) vs. closed
-    // unmerged / never had a PR (the branch is the only copy). Because
-    // hyperhive merges via rebase + fast-forward, the branch's commits
-    // are replayed onto main's current tip as new commits before main
-    // moves — so the original branch tip's SHA is never an ancestor of
-    // main even once merged, and ancestry can't tell these apart; this
-    // is the only signal that can.
+    // unmerged / never had a PR (the branch is the only copy). hyperhive
+    // merges via rebase + fast-forward: a branch needing an actual
+    // rebase gets its commits replayed with new SHAs before main moves,
+    // so its original tip is usually no longer an ancestor — though a
+    // branch that needed no rebase (already current) still is. Ancestry
+    // therefore answers inconsistently, which is why this map exists.
     // Whether the walk below hit `MAX_PAGES` without ever seeing a
     // short page — i.e. there are more PRs than the cap fetched, so
     // `latest_pr_by_head` is missing an unknown number of the oldest