Feature is solid, refactor is clean, one real blocker on the Cloud path.

Blocking

Cloud mixed-identity handling is incomplete in the explicit --reviewer/--remove-reviewer path, plus a silent data-loss bug on AccountID-only reviewers.

The new helpers (cloudUserKeys, sameCloudUser, mergeCloudPRReviewers, cloudReviewerIDs) reconcile all three identity formats and are used for the default-reviewer merge and author exclusion. But matchesCloudUser at pkg/cmd/pr/pr.go:794-799 still only checks UUID or username, and editCloudReviewers at pr.go:808-880 uses it exclusively. The runtime flow at pr.go:1573-1591 merges defaults first (identity-aware), then calls editCloudReviewers (not identity-aware) against the merged reviewer list — so the brittleness surfaces in the explicit add/remove path even when the merge worked.

Repro against the diff:

• Reviewer returned as {UUID: "x", AccountID: "abc", Username: ""} — real for GDPR-era Cloud accounts that never had a username
• --with-default-reviewers --remove-reviewer alice (alice has account_id: "abc"): matchesCloudUser returns false for every check → remove is a silent no-op, alice stays on the PR
• --with-default-reviewers --reviewer alice same case: alreadyOnPR is false → alice appended as a duplicate entry

Plus a silent-drop bug at pr.go:842-857:

if u.UUID != "" {
    result = append(result, u.UUID)
} else if u.Username != "" {
    result = append(result, u.Username)
}

Reviewers with only AccountID populated are silently dropped from the result. cloudReviewerIDs at pr.go:1378-1408 has the same drop. bbcloud.User at pkg/bbcloud/client.go:55-61 confirms all four fields are optional JSON with no guarantees.

Fix: plumb sameCloudUser through editCloudReviewers (replace matchesCloudUser calls), and extend the keep-loop + cloudReviewerIDs serialization to fall back to AccountID when UUID and Username are both empty. Extend the mixed-identity tests you already added (pr_test.go 3116-3156, 4466-4519) to the explicit --reviewer/--remove-reviewer flow.

Non-blocking

1. Author exclusion fragility (pr.go:1575-1579). If Cloud returns an author with no usable identity (rare but possible), cloudUserKeys(excluded) is empty → sameCloudUser returns false → author not filtered → Cloud rejects server-side. Worth a warning + fallback to client.CurrentUser(ctx).

2. Spurious "already on this pull request" warnings at pr.go:1518-1520 (DC) and 1586-1591 (Cloud). --with-default-reviewers --reviewer alice where alice is already in the default set produces noisy stderr. Correct behavior, bad UX — consider suppressing when the overlap is only with freshly-merged defaults, not with pre-existing reviewers.

3. ios, _ := f.Streams() at pr.go:1469 breaks codebase convention — every other runX does ios, err := f.Streams(); if err != nil { return err }. The var err error on line 1472 reads like a workaround for the dropped shadow. Streams() currently never returns a non-nil error so it's harmless today, but please restore the pattern.

4. Four merge functions (mergeReviewers, mergeCloudReviewers, mergeDCPRReviewers, mergeCloudPRReviewers) with different shapes all called "merge reviewers" — rename for callsite clarity.

5. TestRunEditDataCenterReviewers PUT-body assertion is shallow — only checks len(reviewers) == 3, not the actual names. Could miss a regression where the merge produces the right count but the wrong set.

What's done well

• --with-default-reviewers=false is exactly right — tests verify the endpoint is NOT called AND that the Cloud PUT body has no reviewers field.
• DC uses the PR's actual FromRef.ID / ToRef.ID (not repo defaults) — spec-correct.
• Cloud preserves existing reviewer UUIDs in the update payload — matches Cloud's stable identity model.
• Explicit --reviewer/--remove-reviewer applies AFTER the default merge on both backends — explicit user intent wins.
• Default-reviewer fetch errors abort the edit rather than silently continuing.

Once editCloudReviewers and cloudReviewerIDs pick up the account_id-aware logic that the rest of the diff already introduces, this is an approve.

Blocking issue still left in the Cloud edit path.

pkg/cmd/pr/pr.go now preserves/emits AccountID reviewer identities (editCloudReviewers, cloudReviewerIDs), but pkg/bbcloud/pullrequests.go:346-352 still serializes every non-UUID reviewer as {\"username\": reviewer}. For AccountID-only reviewers, bkt pr edit --with-default-reviewers / --remove-reviewer will send an account ID under the username field instead of account_id, which can 400 or silently lose reviewers on Cloud repos that no longer expose usernames.

Please fix the serializer so the update payload emits account_id when the reviewer token is an account ID, and add an end-to-end request-shape test covering the edit flow so this path is exercised outside the helper-level tests.

Re-reviewed the latest head after the serializer fix. The Cloud reviewer identity path now correctly emits account_id for AccountID-only reviewers, the create/update serializers are aligned through a shared helper, and the request-shape coverage is in place. LGTM.