hive-forge: fix stale-branches comment/docs — hyperhive rebase+ff merges, not squash

claude-plugins/plugins/base/skills/forge-triage/SKILL.md

@@ -31,12 +31,12 @@ dimension directly.
 - **Stale branches** - `hive-forge lint stale-branches --days <n>`
   finds remote branches with no recent commits (skips branches that are
   heads of open PRs) and reports each one's merge outcome (PR merged /
-  closed unmerged / no PR at all) — squash-merge ancestry can't tell
+  closed unmerged / no PR at all) — hyperhive's rebase+ff merges mean
-  those apart, so don't delete a stale branch on the age alone; check
+  ancestry can't tell those apart, so don't delete a stale branch on the
-  the verdict first. On a repo with enough PRs to exceed the verb's own
+  age alone; check the verdict first. On a repo with enough PRs to
-  page cap, an old branch's outcome may come back "unknown" instead of
+  exceed the verb's own page cap, an old branch's outcome may come back
-  a verdict — that's not the same claim as "no PR", treat it as
+  "unknown" instead of a verdict — that's not the same claim as "no PR",
-  "can't tell, don't delete" too.
+  treat it as "can't tell, don't delete" too.
 
 ## Using them as a sweep
 

hive-forge/src/verbs/lint.rs

@@ -286,9 +286,11 @@ fn run_stale_branches(client: &Client, args: StaleBranchesArgs) -> Result<()> {
     // 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 squash-merges, a merged branch's tip is never an
+    // hyperhive merges via rebase + fast-forward, the branch's commits
-    // ancestor of main, so ancestry can't tell these apart; this is the
+    // are replayed onto main's current tip as new commits before main
-    // only signal that can.
+    // 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.
     // 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