governance: hand maintainer coverage to community maintainers

[imran-siddique]

The canonical side of the community handover. OPAQUE wound down on 2026-10-12, and its accounts are leaving the organization.

• maintainers/roster.json: primaries and backups move to @lywinged, @rajnisht7, @carloshvp, @zohebk8s and @dinakarjs. OPAQUE accounts come out of every policy and CODEOWNERS entry, and opaque-lt stops being the trace-registry code owner. observed_permissions records only access I read back from the API after granting it.
• This repository's own maintainers.json, CODEOWNERS and gate are regenerated from the roster. MAINTAINERS.md names the new team and moves Qiang and Trish to emeritus.

node scripts/maintainer-roster.mjs validate and node --test scripts/maintainer-roster.test.mjs pass on this branch. Each consumer repository gets its own PR with the matching snapshot.

[dinakarjs]

Technical review at d35b7a8. Local roster validation and all 12 maintainer-roster/gate tests pass; generated .github policy, CODEOWNERS and gate match the proposed canonical source. The WCM entry correctly names zohebk8s as primary and dinakarjs as backup, keeps publisher access unverified, and does not add dinakarjs to the global maintainer list. My current repository permission read confirms maintain access to WCM.

Please reconcile two operational/governance points:

1. maintainers/handover.md is unchanged and still presents Qiang/Trish as current WCM and registry routing/admin coverage, old permission observations and old release-operator pairs. It also says Zoheb has only read access. These instructions now conflict with the proposed roster and #60. Update the operational routing record or clearly mark the old tables as historical and link the current handover. Keep package/environment publisher access separate and unverified until evidence exists.

2. WCM's canonical CODEOWNERS now appends @dinakarjs to /SPEC.md, /THREAT-MODEL.md and /python/ alongside the specialist teams. Multiple owners on a CODEOWNERS line are alternatives; this allows a dinakarjs approval to satisfy code-owner review without establishing a separate spec-editor/SDK-team review. The generated comments and MAINTAINERS.md still say specialist requirements remain, and specialist_access remains unverified. Please confirm and document whether this is an intentional specialist-approval appointment, or preserve specialist-only routing and verify that coverage separately. Repository maintain access and accepting the backup role alone do not establish team membership. The same pattern is already deployed through WCM #193, so clarification should cover the consumer snapshot too.

Also, capacity is still awaiting_acceptance for every repository. #60 already records explicit acceptances from rajnisht7, carloshvp, lywinged and me (my WCM acceptance: #60 (comment)). Please reflect recorded acceptances without inferring acceptance for anyone who has not replied.

These tests establish source consistency and gate behavior, not live team membership, all third-party repository permissions, package publisher roles or organization recovery access. No formal approval, access change or merge performed.