refactor(jans-cedarling): remove redundant `issuer_id` hint from `ProcessedTokenClaims`

## Background

`ProcessedTokenClaims::issuer_id` (jans-cedarling) lets a `CustomTokenProcessor`
tell Cedarling which custom issuer a token belongs to, as an alternative to
resolving the issuer purely from the request's `mapping`. It was added as a
runtime discriminator for the case where `mapping` alone might be ambiguous,
pending #14747.

#14747 is closed (fixed via #14941), and it addressed a different code path
(JWT trusted-issuer key resolution scanning all issuers globally instead of
the specific issuer). It did not touch custom-issuer resolution.

Separately, `CustomIssuerIndex::build` already rejects two custom issuers
declaring the same `mapping` at build time (`DuplicateMapping` error). So a
`mapping` can never resolve to more than one custom issuer at runtime — the
ambiguous-mapping branch in `CustomIssuerIndex::resolve` is unreachable, and
the `issuer_id` hint it exists to disambiguate is dead weight.

## Change

Drop the runtime discriminator entirely:

- `ProcessedTokenClaims::issuer_id` field
- the `issuer_id` parameter on `CustomIssuerIndex::resolve`
- the ambiguous-mapping branch in `resolve` (now unreachable)
- the `UnknownIssuer` error variant (and any other error variant that only
exists to report an unrecognized explicit `issuer_id`), if nothing else
uses it

`resolve` becomes: look up the sole issuer declaring `mapping`, or error if
none does. No behavior changes for existing configs, since the ambiguous case
this hint covered can't occur.

## Why now

Keeping an option that can never legitimately be `Some` (in a way that
changes resolution) is confusing for `CustomTokenProcessor` implementers and
invites them to rely on a code path that no longer does anything.