cli.agentcore sync hardcodes auth_type=IAM for runtimes, so CUSTOM_JWT runtimes get no token-refresh manifest entry

## Summary

`cli.agentcore sync` hardcodes `auth_type: "IAM"` for every Agent Runtime, so a runtime with a `customJWTAuthorizer` never gets a token-refresh manifest entry. The automated egress-token refresh documented in [docs/agentcore.md](https://github.com/agentic-community/mcp-gateway-registry/blob/main/docs/agentcore.md) therefore silently skips runtimes, even though AgentCore runtimes genuinely support CUSTOM_JWT.

## Evidence that runtimes support CUSTOM_JWT

Six runtimes in one account, queried directly via `get-agent-runtime`:

```
sfagentforce_orchestrator proto=None authorizer=NONE/IAM
sfagentforce_caseagent proto=None authorizer=NONE/IAM
iotorchestratoragent_... proto=None authorizer=NONE/IAM
evchargerlocationagent proto=A2A authorizer=CUSTOM_JWT
evcharger2 proto=A2A authorizer=CUSTOM_JWT
ev_charger_location_agent_prod proto=A2A authorizer=CUSTOM_JWT
```

The three A2A runtimes carry exactly the same authorizer shape the gateway path already consumes:

```json
{
"discoveryUrl": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXXXXXX/.well-known/openid-configuration",
"allowedClients": ["4g49m63vei3c2vvog0v7insucn"]
}
```

## The defect

`auth_type` is a literal, set independently of the discovered authorizer, in both runtime registration branches:

- [`registration.py:651`](https://github.com/agentic-community/mcp-gateway-registry/blob/main/cli/agentcore/registration.py#L651) (runtime -> MCP Server)
- [`registration.py:684`](https://github.com/agentic-community/mcp-gateway-registry/blob/main/cli/agentcore/registration.py#L684) (runtime -> A2A Agent)

```python
"auth_type": "IAM",
```

The `CUSTOM_JWT` handling at [`registration.py:166`](https://github.com/agentic-community/mcp-gateway-registry/blob/main/cli/agentcore/registration.py#L166) and the manifest collection at [`registration.py:500`](https://github.com/agentic-community/mcp-gateway-registry/blob/main/cli/agentcore/registration.py#L500) are only reached from the **gateway** path.

Discovery is not the limitation: [`discovery.py:151`](https://github.com/agentic-community/mcp-gateway-registry/blob/main/cli/agentcore/discovery.py#L151) already calls `get_agent_runtime()` and keeps the whole object, so `authorizerConfiguration` is present in memory. Registration just discards it.

## Reproduction

```
$ uv run python -m cli.agentcore sync --dry-run --token-file

Type Name Path Auth Status
runtime evcharger2 /evcharger2 IAM dry_run
runtime evchargerlocationagent /evchargerlocationagent IAM dry_run
runtime ev_charger_location_agent_prod /ev-charger-location-agen IAM dry_run
...
[DRY-RUN] Would write manifest with 0 entries
```

Expected: the three CUSTOM_JWT runtimes reported as `CUSTOM_JWT` and contributing 3 manifest entries.

## Impact

Limited but real. `token_refresh_manifest.json` comes out empty, so `cli.agentcore.token_refresher` has nothing to refresh and cannot keep egress tokens current for these agents. Since the doc states "Cognito gateways need no configuration — the token refresher auto-retrieves client secrets via the AWS API", an operator reasonably expects Cognito-backed runtimes to be handled automatically; they are not, and nothing warns.

This does not block calling the agents. A2A egress is pass-through (the caller supplies the target credential in `Authorization` while `X-Authorization` carries the caller identity), which I verified works end to end once #1595 is fixed:

```
GET /agent/evcharger2/.well-known/agent-card.json -> HTTP 200 (real agent card)
POST /agent/evcharger2/ message/send -> HTTP 200, state: completed
```

So this is about the automated-refresh path, not basic reachability.

## Suggested fix

Derive `auth_type` from the discovered `authorizerConfiguration` rather than hardcoding it, and route runtimes through the same manifest collection the gateway path uses. The existing manifest entry is already generic (`discovery_url`, `allowed_clients`, `allowed_audience`, `idp_vendor`) — a runtime's `customJWTAuthorizer` supplies all of it, so the entry builder should not need changing. The only gateway-specific field is `gateway_arn`, which would presumably become the runtime ARN (or a shared `resource_arn`).

One question for maintainers before I send a patch: was the gateway-only scoping deliberate — the `SyncOrchestrator` docstring says "Collect manifest entries for CUSTOM_JWT **gateways**" — or is it an oversight from runtimes being added later? If deliberate, the docs and the `Auth` column should probably say so, since reporting a CUSTOM_JWT runtime as `IAM` is inaccurate either way.

Happy to open a PR once the intended behavior is confirmed.