feat(api): catch the HTTP API up with the CLI (secret get/set/create-tls, pvcSize)

[anak10thn]

Problem

The HTTP API had drifted behind the CLI. Probed against a running server:

GET   /api/v1/secrets/{name}   -> 405
PATCH /api/v1/secrets/{name}   -> 405
POST  /api/v1/secrets/tls      -> 405

secret get and secret set shipped in v2.10.0 with no endpoints, and secret create-tls never had one — only the generic and docker-registry writers existed.

Change

# keys listed, values withheld
$ curl .../api/v1/secrets/app-config
{"keys":["APP_MODE","DB_PASS"],"managedBy":true,"name":"app-config",
 "namespace":"default","redacted":true,"type":"Opaque"}

# merge one key
$ curl -X PATCH -d '{"data":{"DB_PASS":"rotated"}}' .../api/v1/secrets/app-config
{"keys":2,"name":"app-config","namespace":"default","set":1,
 "note":"running pods keep the old values until restarted"}

• GET /api/v1/secrets/{name} — keys listed, values only with ?showValues=true; 404 for a missing Secret rather than a blanket 500.
• PATCH /api/v1/secrets/{name} — merges, the counterpart to POST which replaces and drops keys it was not given. Creates when absent. The response carries the restart caveat.
• POST /api/v1/secrets/tls — BYO cert from inline PEM (the CLI reads files; over HTTP the contents come inline).

openapi.yaml and docs/API.md updated with all three.

Two things that needed nothing

• x-orcinus-env-from-secret already works over HTTP — conversion runs inside the server process. Confirmed via /convert: the rendered output contains the envFrom/secretRef.
• GET /api/v1/secrets already returned KeyNames, since it serializes the shared type.

Deliberately not changed

SecretInfo keeps its capitalised JSON fields (Name, Keys, KeyNames). They are what openapi.yaml already publishes, so renaming to match the camelCase used elsewhere would break existing consumers. The inconsistency is now noted in the schema description; worth a deliberate breaking change later, not a drive-by one.

Limitation documented, not fixed

Compose keys that point at local files cannot work over HTTP — only the compose text is uploaded, so there is nothing to resolve paths against:

POST /api/v1/convert  with  env_file: .env
{"error":"...: service \"app\": env_file \".env\" not found: /var/.../orcinus-engine-XXX/.env"}

Same for configs:/secrets: with file: and bind mounts. Now called out in API.md, pointing at environment: or x-orcinus-env-from-secret instead. Fixing it properly means multi-file upload, which is a separate design question.

Test harness hazard — please read

Config{Kubeconfig: ""} falls through to $KUBECONFIG, then ~/.orcinus/kubeconfig. So an api test that reached applier() wrote to whatever cluster the machine points at. My new route tests did exactly that and created a kubernetes.io/tls Secret named c on a live cluster (tls.crt: eA== — base64 of the literal "x" from the test body) before I caught it. It has been deleted.

testServer now pins an unresolvable kubeconfig so those routes fail with 503, plus TestTestServerCannotReachACluster fails if that isolation ever breaks. Existing tests never tripped this because they only exercised convert and a plugin 404.

Verification

Live against a real 3-node k3s cluster, through a running orcinus api: create → get (redacted) → get ?showValues=true → patch (merge; the untouched key survived) → create-tls → 404 on a missing name → delete. All test Secrets cleaned up; the cluster's own 7 secrets untouched.

Offline: 151 tests pass, including 4 new api tests (routes wired, writes validate before touching a cluster, openapi covers the new surface, and the isolation guard).