Release v3.7.0

Added

• Client certificates from certificatePath / certificatePassword are now presented on the gRPC channel and the OAuth token request. PKCS#12 (including legacy encryption) and PEM bundles are supported, including certificate chains, UTF-8 key passwords and RSA, ECDSA and EdDSA keys; Ed25519 needs TLS 1.3 on OTP 28.
• The private key stays in a process owned by the connection and is used through an OTP sign_fun, so key material never appears in channel options, process status or crash reports.

Changed

• The announced protocol version is read from the installed cratis_chronicle_contracts package instead of a hard-coded constant.
• With a client certificate configured, server-verification settings must be given on the GRPC.Credential; the same settings in adapter-level transport_opts, or Mint module-level transport_opts, are rejected at startup. Server verification itself is unchanged: Mint/OTP defaults, your credential, or skipTlsValidation.
• The connection docs explain where mutual-TLS settings belong and how to trust a self-signed kernel certificate through cacerts.

Fixed

• A certificate that cannot be read, a wrong password, a key that does not match its certificate, a password without a certificate path, or conflicting identity options now fail at startup instead of connecting without a client certificate. Error messages name the path but never include key material.
• Connection, token-provider and observation-handler process status and crash reports no longer include API keys, bearer tokens or credentials.

Unlike the .NET client, a server that presents the client's own certificate is not trusted automatically (see #77). API keys and bearer tokens can still appear in crash reports from grpc's own response process; that predates this change and is tracked in #79.

Closes #69
Closes #68