chore(jans-cedarling): replace the O(n) token-metadata reverse lookup with a precomputed index

## Replace the O(n) token-metadata reverse lookup with a precomputed index

### Context

The multi-issuer path validates tokens through
`JwtService::validate_multi_issuer_tokens`. For every JWT token it needs to
resolve the token metadata key (`access_token`, `id_token`, …) from the request
`mapping`, which carries the Cedar entity type name (e.g. `Dolphin::Access_Token`).

That reverse mapping is currently done by `IssuerIndex::find_token_metadata_key`
(`cedarling/src/jwt/issuer_index.rs`), which linearly scans **every trusted
issuer and every one of its token metadata entries** until it finds a match:

```rust
for issuer_config in index.values() {
for (token_key, token_metadata) in &issuer_config.policy.token_metadata {
if token_metadata.entity_type_name == entity_type_name {
return Some(token_key.clone());
}
}
}
```

This runs once per token on every authorization request.

### Why this can now be made O(1)

Two recent changes make the lookup unambiguous:

1. `validate_trusted_issuers_config` (`cedarling/src/common/policy_store.rs`)
enforces global uniqueness of Cedar entity types — the same
`entity_type_name` cannot be owned by two tokens/issuers.
2. `EntityBuilder::validate_iss_types` (`cedarling/src/entity_builder/mod.rs`)
rejects token types whose schema `iss` references a foreign namespace.

As a result, `entity_type_name -> token_key` is now a **bijection**: at most one
issuer and one token key match any given entity type name. The "first match
wins" linear scan is therefore correct but unnecessary.

### Proposal

Precompute a reverse index at `JwtService` initialization:

```
entity_type_name -> (issuer_id, token_key)
```

and replace the scan in `find_token_metadata_key` with an O(1) lookup. The
existing `TODO` in `issuer_index.rs` already calls for this. A side benefit:
the `Cow` fallback in `JwtService::find_token_metadata_key` (which returns the
entity type name itself when no key is found) becomes unreachable for a valid
config and can be removed or turned into a defensive error.

### Out of scope

- The `seen_combinations` duplicate detection in `validate_multi_issuer_tokens`
(same issuer + mapping appearing twice in one request) is unrelated and must
stay.
- Custom (non-JWT) issuers resolve their metadata through `CustomIssuerIndex`,
not through this reverse lookup; this issue is JWT-only.