feat(lifecycle): lifecycle: block — maturity, deprecation, compatibility, and komposer acceptance

[iAlexeze]

Lifecycle in Orkestra has always existed as a convention — deprecation lived in metadata, maturity was implied by version numbers, compatibility was communicated in READMEs. This PR makes it a first-class citizen.

A new top-level lifecycle: block now sits alongside metadata, spec, and gateway on every Katalog. It is the contract the pattern author makes with the platform and with consumers:

lifecycle:
  maturity: beta
  deprecation:
    message: "Replaced by task-runner"
    migratedTo: task-runner:v1.0.0
    timeline:
      from: "2026-09-01"
      to:   "2027-03-01"
  compatibility:
    kubernetes: ">=1.28"
    orkestra: ">=0.7.0"

Maturity is a signal — alpha, beta, stable, deprecated. It appears in ork inspect, warns at ork validate, and can be enforced by a platform floor (policy.lifecycle.minMaturity). A pattern that skips it is treated as stable. A pattern that declares deprecated without a deprecation block gets a warning, not a pass.

Deprecation is enforced. The block travels with the artifact into OCI annotations, surfaces at every touchpoint (ork push, ork validate, ork inspect, ork pull), and blocks ork run when the state is active. The author sees exactly what their consumers will see — before the artifact is uploaded.

The acceptance model is deliberate: a deprecated Katalog cannot self-accept. The field doesn't exist on the Katalog type. Acceptance belongs on the Komposer — the consumer making a traceable, reviewable decision about what they are knowingly importing:

# in your komposer.yaml
lifecycle:
  accept:
    patterns:
      - name: legacy-worker
        author: myorg
        version: "=1.0.0"   # optional — scope to a specific version

Compatibility gives pattern authors a way to declare verified version ranges and gives the platform a way to reject patterns that claim to work on Kubernetes 1.24 when the cluster is already on 1.31.

Policy keeps it extensible. Rather than flattening a maturity floor directly under policy:, it lives at policy.lifecycle.minMaturity — making room for future security policy, registry policy, and user-defined policy can grow alongside it without forcing a schema break.

metadata.deprecation is removed. The old accept: { beforeEol, eol } struct is gone. Registry guide get additional lifecycle story as runnable examples.