ci: make DCO a required status check on v2/main (ruleset), after #2619 merges #2621

Problem

No ruleset or branch protection applies to v2/main: gh api repos/modelcontextprotocol/inspector/rules/branches/v2/main returns []. Both "L3 - full protection" rulesets (org and repo) target ~DEFAULT_BRANCH, which is main only.

So once #2619 (#2616) merges, the DCO check will run on every v2 PR, but nothing stops a PR from merging while it's red or missing. A missing check would pass silently, which is how the probot app's outage went unnoticed for seven weeks after #1981 (#2566). #2566 asked for a required check, and #2603 deliberately deferred that part: making it required while the workflow couldn't report would have blocked every PR.

Change

Add a repository ruleset for v2/main, modeled on the existing v1/main - full protection ruleset (19858989):

gh api -X POST repos/modelcontextprotocol/inspector/rulesets --input - <<'JSON'
{
  "name": "v2/main - DCO",
  "target": "branch",
  "enforcement": "active",
  "conditions": { "ref_name": { "include": ["refs/heads/v2/main"], "exclude": [] } },
  "bypass_actors": [
    { "actor_id": 5, "actor_type": "RepositoryRole", "bypass_mode": "always" }
  ],
  "rules": [
    { "type": "deletion" },
    { "type": "non_fast_forward" },
    { "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": false,
        "do_not_enforce_on_create": false,
        "required_status_checks": [ { "context": "DCO", "integration_id": 15368 } ] } }
  ]
}
JSON

• integration_id: 15368 (GitHub Actions) pins the check to the workflow. Without it, anyone with write access could post a commit status named DCO and satisfy the rule. v1/main's ruleset pins build the same way.
• deletion + non_fast_forward: the DCO (v2/main push) backstop checks before..after and assumes v2/main is never rewritten. Today nothing prevents a force-push.
• Bypass: repository admins (role 5), as on v1/main. Drop this if admins should be held to it too.

Preconditions and side effects

1. Apply only after ci: run the DCO check on every v2 PR now, before push, and after merge (#2616) #2619 is merged to v2/main. Before that, PRs get no DCO check at all (the old workflow is pull_request_target, read from main, which has no dco.yml), so a required check would block every merge.
2. Open PRs need one new event. A pull_request run starts only on an event, so a PR opened before ci: run the DCO check on every v2 PR now, before push, and after merge (#2616) #2619 merged has no DCO result until its next push, a close/reopen, or a base edit. Push to (or close/reopen) any open v2 PR that shows the check as "expected".
3. Direct pushes to v2/main will be refused unless the pusher can bypass, because a required check applies to every commit landing on the branch. The release flow uses PRs, so this shouldn't bite.
4. If the next milestone merge lands before ci: run the DCO check on every v2 PR now, before push, and after merge (#2616) #2619, main receives the old pull_request_target dco.yml, and v2 PRs get two DCO checks until the following milestone merge. Both run the same script and agree, so requiring the name DCO stays satisfiable.

Done when

• gh api repos/modelcontextprotocol/inspector/rules/branches/v2/main lists deletion, non_fast_forward and required_status_checks (DCO, integration 15368).
• A test PR with one unsigned commit shows DCO failing and merging blocked. Re-signing the commit unblocks it.
• AGENTS.md ("it gates merges only as a required status check…"), pr-flow step 3 and the dco.yml header no longer describe the requirement as pending.

Out of scope

Requiring build / coverage on v2/main, or a pull_request review rule as on v1/main. Worth deciding, but that's a separate call.