Client authentication: support all token_endpoint_auth_methods

**Priority:** P0 — Critical

### Description

Enhance the wallet's OAuth2 client authentication to support all methods advertised in the authorization server's `token_endpoint_auth_methods_supported` metadata parameter. Currently the wallet only supports `client_secret_basic` implicitly and has Wallet Attestation JWT support. This issue covers `client_secret_basic`, `client_secret_post`.

### Background

Per [OID4VCI §5.5](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-5.5) and [HAIP §4.4.1](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html#section-4.4.1), the wallet MUST authenticate to the authorization server using a method listed in `token_endpoint_auth_methods_supported`. The current `Oid4vciClient` hard-codes the client ID in request bodies and does not inspect this metadata field to select an authentication method.

Additionally, the wallet needs to authenticate for the **credential endpoint** — the same auth method may apply (per issuer metadata) and the token must be presented correctly depending on whether DPoP is also used.

### Scope

1. **Parse `token_endpoint_auth_methods_supported`** from the authorization server metadata (already resolved during offer/metadata resolution).

2. **Implement authentication methods**:
- `client_secret_basic` — HTTP Basic Auth (`Authorization: Basic base64(client_id:client_secret)`). Currently implicit; make it explicit.
- `client_secret_post` — `client_id` + `client_secret` in the POST body.

3. **Client credentials configuration** — extend `Oid4vciConfig` (or the new consolidated `Oid4vcConfig` per #SUB-ISSUE-5) with:
- `client_secret: Option` — for `client_secret_basic`, `client_secret_post`

4. **Method selection logic** — when exchanging the token at the token endpoint:
- Read `token_endpoint_auth_methods_supported` from the authorization server metadata
- Select the highest-priority method the wallet supports (preference order: `client_secret_basic` > `client_secret_post`)
- Fall back to `client_secret_basic` if metadata is absent (per OAuth2 spec default)

5. **Tests**:
- Unit tests for each auth method construction
- Integration test with a mock AS that advertises each method and verifies the wallet sends correct auth
- Test that metadata lacking `token_endpoint_auth_methods_supported` defaults to `client_secret_basic`

### Out of Scope

- Wallet Attestation JWT construction (tracked in #338)
- DPoP proof generation (tracked in #339)

### Acceptance Criteria

- [ ] `token_endpoint_auth_methods_supported` is parsed from AS metadata during offer resolution
- [ ] `client_secret_basic` works (with explicit test)
- [ ] `client_secret_post` works
- [ ] Method selection follows preference order and falls back correctly
- [ ] `Oid4vciConfig` has `client_secret` field (not stored in plaintext in logs/debug)

### Spec References

- [OID4VCI §5.5 — Token Endpoint Authentication](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-5.5)
- [HAIP §4.4.1 — Wallet Attestation](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0.html#section-4.4.1)
- [RFC 6749 — OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749)

Start by tracing Oid4vciClient through offer and authorization-server metadata resolution, then inspect Oid4vciConfig or the consolidated Oid4vcConfig. Review the token and credential endpoint request paths and the existing Wallet Attestation JWT handling. Add unit coverage for authentication construction and mock-AS integration coverage for method selection, fallback, and credential endpoint behavior.

索引モデルが issue の本文から書いたものです。