review-postinglisted

# Review posting (execution only) Turning a decided review selection into what lands on the MR/PR: which findings get a thread, what disposition closes it, how the summary reads, how the close ends. This part owns execution. The decision -- which severity levels post and what disposition closes the review -- belongs to the caller. ## Caller inputs - A decided selection: `{levels: [...], disposition: "comment" | "approve" | "request_changes"}`. `levels` names the severity buckets to post (whichever of Critical / Important / Minor the draft carries); `disposition` names the one the caller already chose. Arriving without both is a caller bug -- see the guard below. - The draft, in the review flow's Strengths / Issues shape: Strengths / Issues (Critical / Important / Minor, each `file:line`) / Assessment (yes | no | with fixes), when it is in context -- take it as given, never re-derive or re-judge a finding here. When the draft is not in context (the parked-resume case), read it from the written report file instead; the report's fixed severity buckets are enough to execute from. - A postable target: an MR/PR whose posting mechanics -- anchoring an inline comment to a line, verifying it landed, composing the summary body -- the caller owns. This part decides how to execute, not what posts or where. - **Callers:** the review verb's Deliver step, a domain adapter's teammate-review skill (the harvest `review` skill, after its thinning pass), or any sessi