workshopctl: add systemd secret retrieval

[tlm]

Summary

Add the workshopctl get-secret plumbing used by systemd
LoadCredential= requests.

The implementation has two paths:

• Plain workshopctl get-secret <sdk>.<secret> forwards a secret request to
  the daemon.
• workshopctl get-secret --systemd handles a request from the Workshop
  secret socket. It reads the peer address of the accepted Unix connection to
  identify the requesting systemd unit and credential, then forwards a normal
  <sdk>.<secret> request to the daemon.

The systemd path writes only credential bytes to stdout. Diagnostics go to
stderr, allowing the socket-activated unit to route them to the journal
without contaminating the credential value.

Systemd behaviour

A systemd peer address has the form:

\0<random>/unit/<unit>/<sdk>.<secret>

For example:

\0<random>/unit/ollama.service/ollama.ollama-api-key

workshopctl decodes this into the requesting unit, SDK, and secret plug.
The systemd response handler implements the secret-spec exit codes:

Result	Exit code	Credential output
Plug not connected	0	Zero-byte credential
Secret not found	1	None
Secret provider locked	2	None
Other failure	255	None
Success	0	Secret value

Current scope

The daemon command currently returns the placeholder value:

workshop-placeholder-secret

It logs the requested secret identifier but never its value. Host secret
provider lookup and secret-interface connection resolution are follow-up work.

This PR depends on the base branch's Workshop secret socket units.

Client refactor

WorkshopCtlOptions now owns its optional stdin reader. This lets local
interceptors consume or clear stdin before forwarding the request to the
daemon. The systemd interceptor clears it after reading the peer address, so
the accepted socket is not buffered into the API request body.

Testing

Added coverage for:

• plain get-secret invocation and non-root access;
• required secret argument validation;
• systemd peer-address parsing and malformed input;
• decoding a peer address from a real Unix socket;
• systemd success and error response handling;
• interception of get-secret --systemd;
• client stdin size limit handling.

Validated with:

go test ./client ./cmd/workshopctl ./internal/overlord/hookstate/ctlcmd

Manual QA

Requires a Workshop build containing both this PR and the Workshop secret
socket units.

1. Launch a new workshop, then enter it as root.

2. Confirm the resolver socket is active:

   systemctl is-active workshop-secret.socket

   Expected output:

   active
   

3. Create a one-shot system service that requests a credential and writes it
   to a temporary file:

   cat >/etc/systemd/system/workshop-secret-smoke.service <<'EOF'
   [Unit]
   Description=Workshop secret smoke test
   After=workshop-secret.socket
   Wants=workshop-secret.socket
   
   [Service]
   Type=oneshot
   LoadCredential=smoke-test.api-token:/var/lib/workshop/run/workshop.socket.secret
   ExecStart=/bin/sh -c 'cat "$CREDENTIALS_DIRECTORY/smoke-test.api-token" > /tmp/workshop-secret-smoke-value'
   EOF
   
   systemctl daemon-reload
   systemctl start workshop-secret-smoke.service

4. Confirm systemd received the credential:

   cat /tmp/workshop-secret-smoke-value

   Expected output for the current placeholder implementation:

   workshop-placeholder-secret
   

5. Confirm the socket-activated resolver processed the request:

   systemctl list-units --all 'workshop-secret@*.service'

   Copy an instance name from the output, then inspect its log:

   journalctl --no-pager -u <workshop-secret-instance>

   The log should identify the requesting unit, SDK, and secret name, but must
   not include the credential value.

6. Confirm the plain command is authorised as the Workshop user:

   sudo -u workshop workshopctl get-secret smoke-test.api-token

   Expected output:

   workshop-placeholder-secret
   

This verifies the success path and systemd transport only. Host keyring lookup,
plug connection state, missing secrets, and locked providers require the future
daemon-side secret resolver.

Docs

• I confirm the PR has no implications for documentation.