Trim the name before matching an API key in disable/enable/revoke

[bluzername]

Fixes #77.

What was wrong

apiKeyNameSchema (z.string().trim().min(1).max(64)) trim the name
at creation time, so dor apikey create ' incident key ' store
incident key, and dor apikey ls show it that way too.

But resolveApiKeyId, the one resolver every management verb use, do
a plain === on the raw argument:

return keys.find((k) => k.name === name && k.revokedAt === null)?.id ?? null;

So an operator or a script that reuse the exact spelling they typed at
creation (with the surrounding spaces) get "no API key named ...",
even if the key is listed right there. revoke is the worse case: it
answers revoked: false instead of throwing, so a credential meant to
be killed can silently stay alive.

Fix

Trim the name inside resolveApiKeyId before the lookup, so it always
compare against the same normalized spelling creation already stored:

const trimmed = name.trim();
const keys = await client.listApiKeys();
return keys.find((k) => k.name === trimmed && k.revokedAt === null)?.id ?? null;

One place fixes it for disable, enable and revoke together, matching
the doctrine already written above that function.

Test

Added disable and revoke resolve a name by the same trimmed spelling creation stored in packages/cli/src/commands.test.ts, following the
issue's own repro: create with extra spaces, disable with the same
untrimmed spelling, then revoke with the trimmed one. Fails before the
fix, passes after.

Also added a changeset (@dormice/cli patch).

Checked locally

• pnpm build
• pnpm --filter @dormice/cli test — 63 passed
• pnpm test (full monorepo) — all green
• pnpm typecheck and pnpm lint — clean

Sorry in advance for any small English mistake, I am not a native
speaker, but the fix itself is small and the test should make it easy
to check.