macos-setup skill Phase 15 cannot register the Cloudflare server: token filename never created, and the agent lacks register_service

## Summary

Phase 15 of the `macos-setup` skill (register the Cloudflare Documentation server) cannot succeed as written. It has two independent defects: it looks for a token file that is never created, and it authenticates as an agent that is correctly denied `register_service`.

Both are reached only after #1568, #1569, #1570, #1572, and #1573 are fixed — before that the run stops earlier — which is likely why they have gone unnoticed.

## Defect 1: the token filename does not exist

Phase 15 hard-codes `agent-test-agent-m2m-token.json` in three places ([SKILL.md](https://github.com/agentic-community/mcp-gateway-registry/blob/main/.claude/skills/macos-setup/SKILL.md) lines 736, 762, 811):

```bash
TOKEN_FILE=".oauth-tokens/agent-test-agent-m2m-token.json"
if [ ! -f "$TOKEN_FILE" ]; then
echo "ERROR: Token file not found: $TOKEN_FILE"
ls .oauth-tokens/
exit 1
fi
```

But Phase 14 runs `credentials-provider/keycloak/get_m2m_token.py --all-agents`, which derives the output name from the *agent config* filename, not the M2M client id ([get_m2m_token.py:171](https://github.com/agentic-community/mcp-gateway-registry/blob/main/credentials-provider/keycloak/get_m2m_token.py#L171)):

```python
json_file = os.path.join(oauth_tokens_dir, f"{agent_name}-token.json")
```

`agent_name` comes from globbing `agent-*.json` and stripping `.json` ([lines 300-315](https://github.com/agentic-community/mcp-gateway-registry/blob/main/credentials-provider/keycloak/get_m2m_token.py#L300-L315)). `setup-agent-service-account.sh` writes its config as `agent-test-agent.json` (agent id, no `-m2m` suffix), even though the client id inside it *is* `agent-test-agent-m2m`. So Phase 14 produces:

```
.oauth-tokens/agent-test-agent-token.json
.oauth-tokens/agent-ai-coding-assistant-token.json
```

Phase 15's existence check fails immediately and the phase exits 1.

## Defect 2: the agent cannot register a server

Correcting the filename gets past the check but the request is then refused:

```
Registration failed: 403 Client Error: Forbidden for url: http://localhost/api/servers/register
```

Phase 12 creates both agents in the `mcp-servers-unrestricted` group (SKILL.md lines 564 and 570). That group grants MCP **server access**, not registry **administration**. Only two scopes carry `register_service`, and neither maps that group:

```
registry-admins granted to groups: ["registry-admins", ...]
mcp-registry-admin granted to groups: ["mcp-registry-admin"]
```

Registry log:

```
User service-account-agent-test-agent-m2m with 1 groups mapped to 0 scopes
User '...' attempted API register without register_service permission
POST /api/servers/register HTTP/1.1 403 Forbidden
```

This is correct authorization behavior — the skill is asking the wrong identity to do the work. Note this is *distinct* from #1574: with #1574's seed fix applied, an agent in `mcp-registry-admin` resolves to `[mcp-registry-admin, mcp-servers-unrestricted/read, mcp-servers-unrestricted/execute]` and registration succeeds. `mcp-servers-unrestricted` still (correctly) grants nothing.

## Verification

On a clean install (volumes wiped, `.env` and `.oauth-tokens/` removed) with the five prerequisite fixes applied, I created a service account in `mcp-registry-admin` and used its token instead:

```
GET /validate -> scopes: ["mcp-registry-admin",
"mcp-servers-unrestricted/read",
"mcp-servers-unrestricted/execute"]
POST /api/servers/register -> Service registered successfully: /cloudflare-docs
GET http://localhost/cloudflare-docs/ -> HTTP 200
```

So the pipeline itself is sound; only the skill's choice of identity and filename are wrong.

## Suggested fix — needs a maintainer decision

The filename is a mechanical correction (`agent-test-agent-token.json`). The identity question is a design call I would rather not make unilaterally, since it defines what the shipped sample agents are *for*:

1. **Add a third, admin-scoped agent** in Phase 12 (e.g. `--agent-id registry-admin-agent --group mcp-registry-admin`) and use it for Phase 15 only. Keeps the two sample agents least-privileged, which seems closest to the current intent.
2. **Put `test-agent` in `mcp-registry-admin`.** One fewer agent, but it makes the primary sample agent an administrator, weakening it as a least-privilege example.
3. **Register via the human admin instead**, using the `INITIAL_ADMIN_PASSWORD` realm user that Phase 10 creates, rather than any M2M agent.
4. **Map `mcp-servers-unrestricted` to a scope that includes `register_service`.** I would recommend against this — it conflates server access with registry administration and would grant every sample agent admin rights.

I lean toward option 1 and can send a PR for it plus the filename fix, but wanted your call on the intended agent model first. Relatedly, it may be worth having `get_m2m_token.py` name its output after the `client_id` in the config rather than the config filename, so `agent-test-agent-m2m-token.json` would in fact be produced — that would make the skill's original expectation correct instead. That is a wider change though, since other callers may depend on current names.