multistore-sts: implement GetCallerIdentity (unblocks aws-actions/configure-aws-credentials)

## Motivation

source-cooperative/data.source.coop#184 aims to make the proxy's `/.sts` endpoint a drop-in AWS STS replacement so standard tooling can exchange OIDC tokens without custom code. `aws-actions/configure-aws-credentials` is the flagship consumer — but after assuming a role it **unconditionally** validates the returned credentials with a SigV4-signed `sts:GetCallerIdentity` call against the configured `sts-endpoint` (no input skips it; 12 retries, then the step fails). multistore-sts currently parses only `Action=AssumeRoleWithWebIdentity` (`request.rs`), so the action can never succeed against a multistore-sts endpoint.

## Proposal

Handle `Action=GetCallerIdentity` in multistore-sts:

1. **Authenticate**: verify the request's SigV4 signature (service `sts`, region-agnostic — clients sign with whatever region they're configured for) against the sealed-token credentials minted by `AssumeRoleWithWebIdentity`.
2. **Respond** with STS-shaped XML: `Account`, `Arn`, `UserId` inside `GetCallerIdentityResult`. The account id should be the fabricated one used in the ARN alias (`000000000000` per #105/#112 discussion) so `AssumedRoleUser.Arn` and `GetCallerIdentity.Account` agree — `configure-aws-credentials` surfaces it as the `aws-account-id` output and checks it against `allowed-account-ids`.
3. **Errors**: unsigned/invalid-signature requests get STS-shaped error XML, not a proxy error.

### Canonical-URI gotcha

AWS SDK JS v3 builds request paths as `basePath + "/"`, so an endpoint of `https://host/.sts` receives `POST /.sts/` — and the client signs the canonical URI `/.sts/`. Signature verification must run over the raw path as sent, not a normalized form (data.source.coop normalizes the trailing slash for routing only).

### Non-goals

`AssumeRole`, `AssumeRoleWithSAML`, session tags — nothing else in the STS surface is needed for the drop-in story.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start in request.rs, where AssumeRoleWithWebIdentity is currently parsed, and trace the request path and credential handling used by multistore-sts. Verify how raw paths such as /.sts/ are preserved for SigV4 validation, then implement the GetCallerIdentity response and STS-shaped errors. Done means signed requests return the required account, ARN, and user ID, while unsigned or invalid requests return STS-shaped errors.

Written by the indexing model from the issue text.