Add a write path to the MCP surface (wispkey_set / wispkey_delete), and optional CA-side cert issuance

[dudetru25]

Problem

The MCP surface WispKey exposes to an agent is read-only. The available tools are:

• wispkey_list
• wispkey_get_token
• wispkey_project_list
• wispkey_proxy_status

There is no way for an agent to store a credential it just created, so any workflow that
mints new key material dead-ends: the agent can create the material, but the only places it can
put it are the filesystem or a host directory, which is exactly what the vault exists to avoid.

Concrete case that hit this

While provisioning an mTLS read path for a private Loki proxy, a Blackbox exporter needed its own
client certificate. Two separate walls:

1. Nothing to sign with. The issuing CA's private key is not in WispKey. Only the CA
   certificate (ca.pem) exists, on the hosts. The vault holds leaf material
   (wia-observability-alloy-loki-client-certificate / -private-key, server certs and keys) but
   no CA key, so there is no reachable way to issue a new leaf under the existing trust chain.
2. Nowhere to put the result. Even after minting a fresh dedicated CA and client cert, there is
   no wispkey_set-style tool to record them, so the new private key has to live as a file on the
   host.

The fallback was to point Blackbox at Alloy's client certificate. That works, but it couples two
components to one identity: rotating or revoking either breaks the other, and the proxy cannot tell
the two callers apart in an audit.

Requested

A write path on the MCP surface. Roughly:

• wispkey_set — create or update a named credential (name, type, value, project, tags,
  description). Should refuse to silently overwrite; require an explicit overwrite: true.
• wispkey_delete — remove a credential, for rotation and cleanup.

Both should be gated so they can be disabled per project or per client, since they are meaningfully
more dangerous than the current read-only tools.

Nice to have, same root cause

PKI-aware operations, so the CA private key can live in the vault and never be handed out:

• wispkey_issue_cert — sign a CSR (or generate a keypair) with a CA credential held inside
  WispKey, returning only the leaf certificate and key.

That keeps the existing "yields tokens, never raw keys" property for the CA itself while making
per-component identities practical, which is the thing that is currently impossible.