feat(review): make the summary call universal and strip the summary object from the review prompt [v0.7]

[devops-thiago]

Problem Statement

The review call is asked to do everything at once. PrReviewPrompts.SYSTEM requires each review response to carry, besides the findings, the full summary object — total_findings, per-severity counts, overall_assessment, pr_purpose, description_gaps, file_summaries, suggested_labels, walkthrough_diagram (PrReviewPrompts.java:588-623), plus the conditionally injected DIAGRAM_REQUEST and label guidance. This inflates both the input prompt and the reserved output budget (REVIEW_OUTPUT_BUFFER_TOKENS), and it is the main reason truncated responses need the elaborate salvage paths in TruncatedResponseSalvager.

The multi-call lane already solved this: batches return findings only, and a dedicated PrSummarizer call (bound to the concise model) produces the summary (FindingPipeline.runMultiCall, summary call at FindingPipeline.java:427). Only the single-call path still uses the mega-contract.

Proposed Solution

Make the dedicated summary call universal:

• Single-call path (FindingPipeline.java:210-248) runs review → refine → summary, same as the multi-call lane. The review response contract shrinks to findings + previous_findings_status.
• Strip the summary spec, diagram request, and label guidance from PrReviewPrompts.SYSTEM/USER; they live only in SUMMARY_SYSTEM/SUMMARY_USER. The summary call also becomes the sole owner of pr_purpose/description_gaps, and gets the real (post-verifier) findings instead of the model guessing counts up front — today the review call fills counts before the verifier has rejected anything.
• Token accounting moves with it:
  • DiffBudgetPlanner.plan overhead estimation concatenates the actual prompt constants (DiffBudgetPlanner.java:305-314) — update for the slimmer prompts.
  • The single-call lane becomes 2 review-lane calls minimum (review + summary, verifier on top); revisit the maxAiCalls - 1 summary reservation (DiffBudgetPlanner.java:316) so both lanes account identically.
  • REVIEW_OUTPUT_BUFFER_TOKENS (default 8192) can likely shrink for the findings-only call; the summary call already has its own REVIEW_CONCISE_MAX_OUTPUT_TOKENS.
• TruncatedResponseSalvager.salvageTruncatedSingleCall simplifies: a findings-only array is much easier to salvage than findings-plus-summary (see A truncated single-call review is discarded whole; only the multi-call lane salvages #580 for the history here).

Expected wins

• Smaller input and output on every review call — this is pure token savings on the hottest call in the system.
• The summary keeps working even when a review response is truncated (it is generated from parsed findings, not embedded in the same response).
• One prompt per concern: review guidance and summary guidance evolve independently.

Touchpoints

review/ai/PrReviewPrompts.java, review/FindingPipeline.java (single-call path), review/DiffBudgetPlanner.java (overhead + call reservation), review/ai/TruncatedResponseSalvager.java, review/ReviewPromptAssembler.java (diagram/label guidance re-targeting), review/ai/PrReviewPromptsContentTest.java.

Acceptance criteria

• Eval corpus (-Peval) green; PrReviewPromptsContentTest guidance pins updated, none silently dropped.
• Rendered summary comment (PrSummaryGenerator) equivalent for users on both lanes.
• Per-review token metrics (gen_ai.client.token.usage) show reduced input+output for the review call; no regression in previous_findings_status handling.

Alternatives Considered

• Keep the dual contract and only shorten the summary spec — retains the salvage complexity and the double-ownership of summary fields.