[aside] aside-on-stop の ahead>0 ゲート(PR #357)は主要な空振りを潰したが、残存エッジケースが2つ ── 完全に閉じるには HEAD sha 比較でなく未マージ commit の集合/数で追う必要

PR #357(work-boundary nudge を「HEAD が動いた」から「HEAD != seen かつ origin/main..HEAD が非空」に絞った)実装中に自覚した、今回あえて取らなかった残り。

- 事実: 新ゲートは `HEAD != seen`(sha 比較)を保ったまま `ahead>0` を AND しただけ。branch switch-to-main / 新 main への rebase / fetch(ahead=0)は確実に潰れる。だが:
  1. **rebase 二重発火**: commit したターンで一度 nudge → `seen` 前進 → 別ターンで `git rebase` すると commit の sha が変わり `HEAD != seen` 再成立 + ahead は依然 >0 → 同じ work でもう一度発火。通常 flow は commit+rebase+push を1ターンに束ねる(Stop は1回)ので稀だが、ターンを跨ぐと顕在化。
  2. **別 in-progress branch への切り替えで発火**: origin/main より進んだ別 feature branch に `checkout` すると ahead>0 かつ HEAD!=seen → 新規 authored work がそのターンに無くても発火。
- 根本: sha 一致(`seen`)で「計上済か」を判定しているのが両者の原因。rebase は sha を変え、branch 切替は別の ahead>0 sha に飛ぶ。

→ 触らない判断: PR #357 は体感頻度の主因(bare HEAD move での空振り)を最小変更で潰すのが scope。残り2件は頻度が低く、閉じるには状態を「sha」から「未マージ commit の patch-id 集合 or ahead 数の差分」へ持ち替える必要があり、複雑さに見合わないと判断。
→ 想定インパクト / トリガー: ターンを跨いで rebase する運用、複数 feature branch を行き来する session。直すなら state を `seen_ahead`(ahead 数)に替えて「ahead が前回計上値より**増えた**ときだけ発火」にする ── ただし別 branch 切替で ahead 数が同じだと取りこぼす副作用があり、patch-id 追跡が要る。レバー A の次に頻度が問題なら検討。関連 PR #357。