feat(compose): x-orcinus-env-from-secret — load an existing Secret as env vars

[anak10thn]

Problem

There was no compose-native way to consume a Secret that already exists in the cluster.

x-orcinus-secret reads like it should do this, but it does the opposite — it creates a Secret from values written in the compose file. So referencing one made by orcinus secret create left two options, both bad:

• compose secrets: + external: true — mounts it as a file, and only really fits a Secret holding a single value (details below)
• drop the whole workload to a raw manifest for envFrom.secretRef — which passes through untouched and therefore gets no orcinus labels, so it disappears from orcinus ls and from --prune scope

Change

services:
  app:
    image: myapp:1.0
    x-orcinus-env-from-secret: app-secret      # or [app-secret, extra-secret]

# →
containers:
- envFrom:
  - secretRef:
      name: app-secret

Every key in the Secret becomes an env var under its own name. Nothing is generated for the Secret — it must exist at deploy time.

Applied next to applyImagePullSecrets, before Rollout conversion, so StatefulSets and Argo Rollouts inherit it (covered by a test). The reference is appended after any env_file ConfigMap, so a key in both resolves to the Secret's value — which is the point of naming a Secret.

Docs

While answering "how do I attach app-secret?" it turned out the file-mount route works but was documented nowhere — COMPOSE.md only mentioned file:. Now written down, including two sharp edges found by testing:

• the key in the secrets: map must equal the Secret's name in the cluster — a name: field is silently ignored
• the Secret must contain a data key of that same name; target: renames the file, not the key. orcinus secret create app-secret --from-literal DB_PASS=x then mounting it leaves the pod stuck on the missing key

Also worth flagging for reviewers: the fork logs level=warning msg="External secrets app-secret is not currently supported - ignoring" while wiring it up correctly. The warning is wrong; it is not from this PR, and I left it alone.

Discoverability, since the original confusion was "I made the secret, now what":

• orcinus secret create now ends with — load it into a service with \x-orcinus-env-from-secret: ``
• the secrets skill card said how to make a secret but never how to consume one; it now covers both, and warns that x-orcinus-secret is not the way to reference an existing one

Tests

Four cases: scalar form, list form (order preserved), ordering after an env_file ConfigMap, and inheritance by StatefulSet + Rollout. Full suite 137 passing.