feat(tsa): parse RFC 3161 requests and sign timestamp tokens

[Bugs5382]

What and why

Second of the RFC 3161 time-stamp authority PRs (task 3 of the issue): request parsing and token
building in internal/tsa, on the hand-written CMS package. Still not wired into boot; the listener and
the config mapping follow.

Responder.Respond takes a DER TimeStampReq and always answers with a DER TimeStampResp.

Requests (RFC 3161 section 2.4.1):

• Version 1 only. The message imprint must be SHA-256, SHA-384 or SHA-512 (parameters absent or NULL)
  with a hash of the right length.
• SHA-1, MD5 and any other algorithm get badAlg. A different reqPolicy gets unacceptedPolicy.
• Any request extension gets unacceptedExtension, as section 2.4.1 requires for one the server does
  not recognise. This TSA recognises none.
• Malformed or trailing bytes get badDataFormat. A signing failure gets systemFailure.
• The rejection's statusString says what the failure bit means. The detail goes to the log only.

Tokens (section 2.4.2, RFC 5816):

• The TSTInfo echoes the message imprint byte for byte and the nonce, and names the configured policy.
• The serial number is 159 random bits from crypto/rand: positive, within the 160 bits requesters must
  handle, and unique per token.
• genTime is UTC GeneralizedTime to the millisecond, with trailing zeros dropped. encoding/asn1
  only writes whole seconds, so it is hand-encoded.
• accuracy is seconds plus millis, from the configured value. ordering is left at its default,
  FALSE. The tsa name and extensions are left out.
• The SignedData (id-ct-TSTInfo, version 3) is built by internal/cms and signed by the TSA key
  through CertManager.WithSigner. The signer is identified by issuer and serial number.
• The signed attributes are content-type, message-digest and signing-certificate-v2. Its one
  ESSCertIDv2 has the SHA-256 hash of the TSA certificate (the DEFAULT algorithm, so DER leaves it out)
  and the certificate's issuer and serial.
• The digest is the one the node pairs with the key when it signs certificates (SHA-384 for P-384 and
  RSA 3072 or larger). A P-384 TPM key only signs SHA-384 digests.
• The TSA certificate is carried only when certReq is set.

Refs #287

Merge order: after #351 (merged). The listener PR follows this one.

No docs change in this PR: nothing is user-facing until the config mapping lands, and the docs PR
ships with that one.

Verification

• Lint clean
• Tests pass
• Build succeeds
• Documentation updated (if behavior or API changed): not yet user-facing, see above

How this was verified

task ci and task license pass locally.

The tests check the tokens independently of the encoder:

• They parse the response with their own RFC 3161 structures over encoding/asn1, and verify the
  SignedData with cms.ParseSignedData and Verify.
• They check the ESSCertIDv2 hash, the issuer and serial, and that the hash algorithm is omitted.
• They check the imprint, nonce, policy and serial, and the exact genTime and accuracy encodings.
• They check that the failure bit is the only bit set and the last one in each rejection.
• They check that 64 tokens get 64 distinct serials, and cover both P-384 and RSA 3072 TSA keys.

openssl ts (OpenSSL 3.6) builds SHA-256, SHA-384 and SHA-512 queries, with and without a nonce,
certReq and the policy. openssl ts -verify checks each reply against the CA, from both the query file
and the data, for both key types. It reports Verification: OK. openssl ts -reply -text shows the
policy, the accuracy and Ordering: no, and reads a SHA-1 query's rejection as an unsupported
algorithm.

As a mutation check, making the EKU non-critical makes openssl ts -verify fail. Dropping the
ESSCertIDv2 issuerSerial fails the parser tests. The OpenSSL tests skip without OpenSSL 3 locally but
fail under CI, like the CMS package's.

[Bugs5382]

Closing summary: adds the RFC 3161 request parser and token builder (Responder) to internal/tsa: SHA-2 imprints only (badAlg otherwise), policy, extension and format checks, TSTInfo with echoed imprint and nonce, 159-bit random serial, millisecond genTime, accuracy, and a SignedData via internal/cms with signing-certificate-v2 (RFC 5816). Tokens are verified in tests by the stdlib parser and by openssl ts -verify. CI green.