revert: move experimental AdCP 3.3 identity from main to next

[bokelley]

What

Reverts #1502 (3961d1cf, "feat(identity): add experimental AdCP 3.3 agent identity") on main. The code stays on next, which already contains it.

Why

main releases the 9.x line on AdCP 3.2.x. #1502 tracks AdCP 3.3 drafts that keep changing until 3.3 is ratified, so leaving it on main ships draft code in 9.0.0-beta.4 (#1465) and in every later 9.x release. Under the branch model in #1525 (cross-SDK tracking: adcontextprotocol/adcp#8118), draft-spec work lives on next, which now releases 10.0.0-alpha.N pre-releases from its own Release Please setup. #1502 hasn't shipped in any release yet, so removing it now doesn't break anyone.

Merge this before #1465 (the 9.0.0-beta.4 release PR). After this merges, release-please regenerates #1465 with this revert in it.

Conflict resolution and dependent commits

Eight commits landed on main after #1502. Three of them touch #1502's files (#1504, #1507, #1532).

• Only src/adcp/client.py conflicted. feat(property-lists): unify resolution and validate seller inventory #1532 added product_property_policy to ADCPClient and ADCPMultiAgentClient right next to feat(identity): add experimental AdCP 3.3 agent identity #1502's experimental_agent_identity. The resolution keeps product_property_policy: its parameter, docstring, attribute, and forwarding to per-agent clients. It removes only the experimental_agent_identity parameter, docstring, attribute, and forwarding.
• The other files merged without conflicts. For every file feat(identity): add experimental AdCP 3.3 agent identity #1502 touched, the diff between feat(identity): add experimental AdCP 3.3 agent identity #1502's parent and this branch matches the diff between feat(identity): add experimental AdCP 3.3 agent identity #1502 and current main line for line. So this PR removes exactly feat(identity): add experimental AdCP 3.3 agent identity #1502 and keeps every later change.
• No later commit depends on feat(identity): add experimental AdCP 3.3 agent identity #1502's code. mypy src/adcp passes, the package imports, and nothing references the removed modules (adcp.types.experimental_identity, adcp.signing.wba, adcp.signing.trust, the _identity_schemas bundle, and so on).
• Nothing in the revert was skipped.

Keeping #1502 on next (required step after this merges)

The trap: when next next takes main, this revert comes along and deletes the identity code from next too. Record the revert on next as merged without applying it. A maintainer runs this once, right after this PR merges, before anyone else merges main into next:

git fetch origin
git switch next && git merge --ff-only origin/next
REVERT=<sha of this PR's commit on main>          # git log origin/main --grep 'move experimental AdCP 3.3 identity' -1
git merge --no-edit "$REVERT^"                     # 1. main up to just before the revert, as a normal merge
git merge -s ours "$REVERT" -m "chore: record main's revert of #1502 as merged; next keeps the identity code"   # 2. revert recorded, not applied
git merge --no-edit origin/main                    # 3. the rest of main, as a normal merge
git diff "$REVERT^" HEAD --stat -- src/adcp/signing/wba.py src/adcp/types/experimental_identity.py   # still present: no deletions
git push origin next

Push the merges straight to next, or open a PR and merge it with Create a merge commit. A squash or rebase merge drops the -s ours parent, and the next sync would delete the code again.

The equivalent alternative is to merge origin/main into next as usual, then run git revert <REVERT> on next to revert the revert. That gives the same tree, but it reports modify/delete conflicts wherever next (#1514, #1523) has changed #1502's files. The -s ours sequence avoids those conflicts, so prefer it.

Can this be done before the merge? Only if this PR is merged with Create a merge commit, which keeps this branch's commit as-is. In that case a maintainer can run steps 1 and 2 now, with REVERT set to this branch's head and REVERT^ = the current main base, and later syncs carry no deletion. With the repository's usual squash merge, main gets a new commit and the pre-merge step doesn't apply, so I haven't run it. Run the post-merge procedure above. The same procedure is written up in RELEASING.md (#1535).

Checks

• mypy src/adcp: clean. ruff check src/: clean.
• Local pytest tests -n 6 without the Postgres reporting conformance lane (tests/conformance/reporting): 14324 passed, 140 skipped, 1 xfailed, 0 failed. CI runs the full suite, Postgres lanes included.

Refs #1525, #1535, adcontextprotocol/adcp#8118.

🤖 Generated with Claude Code

[aao-secretariat]

Ladon verdict: Approve

Approve — clean revert of #1502 (experimental AdCP 3.3 identity), 58+/15056−.

What was checked:

• client.py conflict resolution is correct: keeps product_property_policy (parameter, docstring, attribute, per-agent forwarding at :425,:444) and removes only experimental_agent_identity (:424,:441-443).
• Largest modified file signed_requests.py (627 deletions) is a faithful revert — apply_verified_signer restored to the base AuthInfo.from_verified_signer form (:2333), WBA authorization/spend-committing branches dropped, no residual references to removed helpers.
• No stranded references: git grep over HEAD for experimental_agent_identity, check_wba_authorization, WbaSignerKeyResolver, trust_grant_gate, verify_wba_request, signing.wba/trust, trust_grants, experimental_identity returns nothing. GetPrincipalResponse/cast/R remain used so no dead imports.
• Semver: #1502 ships in no release (latest v9.0.0-beta.3 predates it), so removing these public exports breaks no shipped adopter; revert correctly sequenced before beta.4 cut. No major needed.

Reviewer surfaced no critical/high/medium findings.

Note on high_risk: the flag is true and includes several (deleted) entries under sensitive globs (src/adcp/signing/, src/adcp/decisioning/). However, every deleted file was introduced by the never-shipped #1502 and is being removed to return main to its prior state — not a destructive change to load-bearing production code. The reviewer confirmed no stranded references and no regression. With zero findings and the deletions being a clean revert of unshipped code, this falls through to approve (row 9). Decision-table rows 1 (no critical/high), 2 (gated_paths false), 4-8 (no medium, no team gate) do not fire; row 3 is a heuristic escalation for destructive changes, but the evidence here shows a faithful revert of unreleased code with no actionable finding.