feat(trusted-issuer): expose enable_token_review and apiserver URL

[lakhansamani]

Found while auditing the SDKs against the current server surface.

Kubernetes TokenReview was unreachable from Python

The server accepts enable_token_review and kubernetes_api_server_url on _add_trusted_issuer / _update_trusted_issuer and returns them on TrustedIssuer. This SDK had neither:

• the request dataclasses had no such fields, so they could not be sent
• TrustedIssuer.from_dict passes through _known(), which drops unknown keys — so even when the server returned them, they were silently discarded
• TRUSTED_ISSUER_FRAGMENT didn't select them, so GraphQL never asked in the first place

Not awkward to use — impossible. Online TokenReview validation could not be configured from Python at all.

The fix

The pair added to AddTrustedIssuerRequest, UpdateTrustedIssuerRequest and the TrustedIssuer response, plus the GraphQL fragment.

Documented at the field, because two things about them are easy to get wrong:

• kubernetes_api_server_url is required and must be https whenever enable_token_review is true — the server rejects the write otherwise, and on update it validates the merged row, so enabling review without a previously stored URL also fails.
• It is security-sensitive: the server authenticates that call with its own in-cluster ServiceAccount token, so whatever host is configured receives that credential.

Verified against a live server

Not just unit tests — a real server, set and read back:

SET  enable_token_review       -> True
SET  kubernetes_api_server_url -> https://k8s.example.com
READ enable_token_review       -> True
READ kubernetes_api_server_url -> https://k8s.example.com

117 unit tests pass. (The tests/integration suite needs a live server and fails with connection errors without one, unchanged by this PR.)

Also corrected

A comment listed spiffe_bundle_endpoint as a valid key_source_type. It has no fetcher server-side and is now rejected at write time, so a caller following that comment gets an error.

Note on the Go SDK

The same gap exists there and cannot be fixed in that repo alone: authorizer-go pins authorizer-proto-go v0.2.0-rc.1, whose generated types predate these fields. The proto repo's main has them on all three messages — it needs a tag cut, then a go.mod bump, then the GraphQL field-selection update. Filed separately rather than half-fixed here.