feat: メンション対象の通知を別の投稿に分けて送る

[limit7412]

issue #120 の案C（同一チャンネルへの分割投稿、時系列は維持）の実装。

やったこと

メンション対象の通知とそれ以外を、別々の投稿に分けて送るようにした。
両者が同じ投稿に混ざると、@channel が付いていても、どれが自分宛てなのかは投稿を開くまで分からない。
important? が切り替わる位置で投稿を区切ることで、@channel の付く投稿には自分宛ての通知だけが入る。

古い順に「通常・メンション・メンション・通常」と届いた実行なら、投稿は「通常 1 件」「メンション 2 件」「通常 1 件」の 3 つになる。
チャンネル上の並びは従来どおり時系列で、投稿の境界だけが増える。

変更点

Notify::Message#important? を追加した（1 コミット目）

送信先に依存しない重要度フラグを持たせ、Github::Usecase#build_message で設定する。

判定は reason だけで行い、CI によるメンション抑止（#105）は反映しない。
抑止は「レビューできない PR でチャンネル全体を叩かない」ためのもので、通知の重要度を下げるものではない。
両者を同じフラグにすると、CI が赤いレビュー依頼が通常の通知に混ざってしまう。
結果として、CI が赤い PR では @channel だけが従来どおり抑止され、投稿はメンション対象側に入る。

Notify::Usecase#send_split を追加した（2 コミット目）

important? が同じ値で連続する区間ごとに、アダプタの send_messages を呼ぶ。

区切るのは並べ替えではなく分割なので、通知は updated_at 昇順のまま送られる。
既読化は「送信済みは常に先頭からのプレフィックス」であることに依存しているため（#94 / #100）、この順序は保つ必要がある。
区間ごとの yield には直前までの区間の合計を足し、既読化に渡る累計を分割前と一致させている。

README を更新した（3 コミット目）

投稿の分割と、あわせて既存の CI によるメンション抑止（#105）をメンション節に書き足した。

Slack の webhook 応答を検査するようにした（5 コミット目）

Slack::PostRepository#send_post が @client.post の戻り値を捨てていたため、429 や 5xx で投稿されなかった場合でも yield messages.size に進み、呼び出し側がその通知を既読化していた。
表示されないまま消える通知が出るので、失敗は例外にして既読化を止める。

バグ自体は以前からあったが、重要度で投稿を分けたことで 1 実行あたりの投稿数が増え、レート制限に当たりやすくなった。
一時的な失敗でその実行を丸ごと落とさずに済むよう、429 と 5xx は Retry-After に従って再送する。
待機上限（5 秒）と試行回数（3 回）を含め、方針と定数は既存の Discord::PostRepository に揃えた。

再送ロジックが Slack と Discord で重複した。
共通化は notify 層に HTTP の知識を持ち込むか新しい抽象を足すことになり、この PR のスコープを広げるため見送っている（#123）。

プランからの変更

issue のプランでは Notify::SplitPostRepository というデコレータを notify 層に足し、main.cr で既存の poster を包む形にしていた。
これはコンパイルできなかったため、Notify::Usecase に置く形に変えている。

デコレータは自身も Notify::PostRepository なので、委譲先 @poster の静的型にデコレータ自身が含まれる。
Crystal は yield するブロックを常にインライン展開するため、@poster.send_messages(run) { yield ... } の展開が無限再帰する（Error: recursive block expansion）。
ブロックを Proc として捕捉する形も試したが、同一の仮想呼び出しに yield 版と捕捉版の実装が混在することになり、これも通らなかった。

置き場所としても、累計の正しさは既読化の境界と表裏なので、mark_read_through と同じファイルにあるほうが不変条件を一箇所で追える。
環境変数の追加も main.cr の変更も不要になった。

影響範囲

• Discord のアダプタは無変更。Slack は応答検査と再送を足したが、投稿の組み立ては変えていない。
• Slack は従来 1 投稿だったが、区間ごとの投稿になる。通常とメンション対象が交互に届く実行では投稿数が増える（最悪で通知件数ぶん）。毎分実行で 1 回あたりの件数は少ないため許容した。
• Discord は区間を受け取ったあと、既存の 10 embeds / 6000 文字のチャンク分割がその中で行われる。@everyone はメンション対象の区間のチャンクにだけ付くようになり、従来（チャンク内に 1 件でもあれば付く）より正確になる。
• メンション対象が 1 件も無い実行では区間が 1 つになり、投稿のされ方は変更前と一致する。
• アラート（Error::Usecase）は send_message で 1 件ずつ送るため分割の影響を受けない。ただし Slack の応答検査は効くので、これまで握りつぶしていた送信失敗が例外になる。

テスト

crystal spec は 119 examples, 0 failures。追加したのは以下。

投稿の分割（spec/notify/usecase_spec.cr, spec/github/usecase_spec.cr）

• メンション対象とそれ以外を別々の投稿に分けること
• 投稿を分けても updated_at 昇順のまま送ること
• 重要度が変わらなければ 1 投稿にまとめること
• 投稿を分けても既読化の境界が分割前と変わらないこと
• 投稿の途中で失敗したら送信済みの投稿までしか既読化しないこと
• reason がメンション系なら important になり、CI が赤い PR でも important のままであること

Slack の応答検査（spec/slack/repository_spec.cr）

• 429 が続いたら 3 回試行して例外にし、yield しないこと
• 5xx も同様に yield しないこと
• 429 のあと成功したら yield すること
• 恒久的な 4xx は再送せず即例外にすること

送信部を post_json に切り出し、HTTP を張らずに応答を差し替えている。
修正前の実装（応答を捨てる）に戻すとこのうち 4 件が落ちることを確認した。

検証環境について

この環境ではネットワーク制限により Crystal 1.21.0 を用意できず、Ubuntu の 1.11.2 で検証している。
1.11 ではフォーマッタが複数行引数の末尾カンマを落とすためリポジトリ全体に差分が出る。
crystal tool format は実行せず、追加分だけを既存の記法に手で合わせた（CI の --check で確認済み）。
ameba は 1.11 でビルドできずローカル実行できなかったため、初回の CI で Style/VerboseBlock の指摘を受けて 4 コミット目で直している。

Closes #120

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ccc000f29f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".