feat(github): dispatch apply comment on deployment count

[Kiran01bm]

What and Why ?

Wires the apply-comment path end to end: storage → presentation → render. Chooses the single- or multi-deployment renderer based on how many apply operations the apply owns, so single-deployment PRs are byte-for-byte unchanged and multi-deployment PRs get the new aggregated comment.

Changes

• pkg/webhook/apply.go: extract shared tableProgressFromTasks(...) helper used by the existing single-deployment comment builder.
• New pkg/webhook/multi_apply.go: dispatcher that
  • with <= 1 operation, uses the existing single-deployment renderer unchanged;
  • with >= 2 operations, maps []storage.ApplyOperation to presentation.Operation, groups tasks by ApplyOperationID, derives the presentation model, and renders the multi-deployment comment.

Stacking

Final piece of the MD-10 per-deployment presentation series, on top of #315 (model) and the renderer PR.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[aparajon]

The dispatch threshold (<=1 op → existing renderer byte-for-byte, >=2 → aggregate) and task routing by ApplyOperationID are right, and the policy resolution at the storage→presentation boundary is the correct seam. Three items:

1. formatApplyStatusComment has no production callers — comment_observer.go and rollback.go still call formatProgressComment directly, and no call site fetches operation rows, so the dispatcher is dead code as merged. If the wiring is intentionally a follow-up, the description should say so (it currently claims end-to-end wiring). If it lands here, note the fail-closed question: a ListByApply error must not silently render the single-deployment comment for an apply that has siblings — that would hide a sibling failure from the PR.

2. Build conflict with feat(config): add on_failure enum for rollout continuation #317 — this reads op.HaltOnFailure (*bool), which feat(config): add on_failure enum for rollout continuation #317 replaces with the on_failure enum; the two PRs can't merge independently as written. Suggest mapping from the enum here (and carrying the enum into presentation.Operation so a future pause doesn't need a re-plumb).

3. Inner footers compete with the aggregate next-action — each deployment's <details> body inherits the single-deployment footer, so a deployment that isn't next in order can still render its own cutover command with the parent apply ID. Consider suppressing the inner footer in multi-deployment sections, or scoping it to the deployment the aggregate names. Related: buildDeploymentDetail shows the parent apply's database and timestamps in every section rather than op.Target and the operation's own timestamps.

Since this PR already has an approval, suggest new commits rather than a force-push.

---

🤖 This review was generated by Claude Code (claude-fable-5) with maintainer approval.