bug(unic-pr-review): every ADO Writer az invoke uses wrong --resource/--api-version — all --post writes fail (`--resource and --api-version combination is not correct`)

Summary

Every az devops invoke write in agents/ado-writer.md uses --resource threads / --resource comments with --api-version 7.0. The Azure DevOps CLI rejects that combination outright, so every write operation fails and --post cannot post anything to a PR. The same wrong resource names appear on the read side in agents/ado-fetcher.md.

Correct names are pullRequestThreads and pullRequestThreadComments, at --api-version 7.1.

Reproduction

$ az devops invoke --area git --resource threads --api-version 7.0 \
    --route-parameters project=dxp repositoryId=DXP-Website pullRequestId=5647 \
    --org https://dev.azure.com/FZAG --http-method GET
ERROR: --resource and --api-version combination is not correct
$ echo $?
1

Control, same PR, same credentials:

$ az devops invoke --area git --resource pullRequestThreads --api-version 7.1 \
    --route-parameters project=dxp repositoryId=DXP-Website pullRequestId=5647 \
    --org https://dev.azure.com/FZAG --http-method GET -o json | jq .count
104

The failure is not version-specific to 7.0 — the ADO Fetcher reported trying 7.1, 6.0, 5.1, 5.0 and 4.1 with --resource threads and all failing identically. The resource name is what's wrong; the api-version is incidental.

Affected locations

apps/claude-code/unic-pr-review/agents/ado-writer.md — all six write invocations:

apps/claude-code/unic-pr-review/agents/ado-fetcher.md has the same problem on the read path. It is less visible there because the Fetcher is an LLM agent that recovered on its own — from a real run:

threads fetch: az resource name 'threads' with --api-version 7.0 is rejected by this az devops CLI … Fetched successfully via --resource pullRequestThreads --api-version 7.1 instead. All 64 threads retrieved — no data lost.

So the read path silently self-heals and the bug survives; the write path also self-healed in my run, but only after failing all 51 operations first.

Impact

--post is broken as specified. In a real re-review of ADO PR 5647 (14 thread actions + 36 inline Findings + 1 Summary = 51 writes), the first attempt failed all 51.

Two mitigating facts worth noting for triage:

• No partial state. Because the CLI rejects the invocation before issuing any HTTP request, nothing landed — a re-read confirmed the thread count unchanged at 67. So there is no duplicate-comment hazard on retry (cf. #46), and the ADR-0015 Write Retry path is not implicated.
• Agents work around it. Both the Fetcher and the Writer are LLM agents that discovered the correct incantation themselves and completed successfully. That is precisely why this has stayed latent: the plugin appears to work while its documented contract is wrong. Any deterministic reimplementation of these steps, or a less persistent model, fails outright.

Suggested fix

Mechanical substitution across both agent files:

• --resource threads → --resource pullRequestThreads
• --resource comments → --resource pullRequestThreadComments
• --api-version 7.0 → --api-version 7.1

Two things worth pairing with it, since the workaround-friendliness is what hid this:

1. A smoke test. #120 mentions an "ADO CLI smoke test" — a read-only pullRequestThreads GET asserting exit 0 would have caught this and would catch the next CLI resource-name drift. /unic-pr-review:doctor is a natural home.
2. Note the CLI version dependency. These resource names come from the azure-devops CLI extension's own routing table, not the REST API, so they can drift independently of the api-version. Worth a comment in the agent files so the next person doesn't "fix" them back toward the REST path names.

Also worth a look (separate concern, not filed)

ado-writer.md Step 7b instructs the Writer to PATCH the existing Summary comment in place. In a re-review where the Coordinator plan resolves the prior Summary thread, that buries the new Summary inside a thread which is then resolved — the Writer in my run deviated to the Step 7c create-new path to avoid it. If that deviation is correct, Step 7b should say when to prefer 7c; if not, the Coordinator should not be resolving the prior Summary thread. Happy to split this out if useful.

Environment