feat: formalize component lifecycle model and CI validation

[rhartuv]

Goal

Formalize the component lifecycle model for skills, plugins, and MCP servers in the agentic-plugins repository.
Define the valid lifecycle states, document them as a canonical reference, and enforce them via CI validation.

Context

The spec.lifecycle field in Compass manifests (catalog-info.yaml) already exists and is used by all components. Currently the progression development < beta < production is defined in relationship-rules.md, and a ceiling validator (APPENG-6307) enforces that a skill cannot exceed its parent pack's lifecycle.

However, the current model is incomplete:

• No deprecated or archived states — there's no declarative way to retire a component
• production should be renamed to GA (Generally Available) to align with Red Hat terminology
• No CI validation that the value is one of the allowed set (only the ceiling rule is enforced)
• No documentation for component owners on how to manage lifecycle transitions
• The catalog publication pipeline (APPENG-6026) needs lifecycle awareness for routing (tracked separately as a sub-task of APPENG-6026)

JIRA

Summary- what changed

• Formalize the component lifecycle model for skills, pack plugins, and MCP servers. Valid spec.lifecycle values are development, beta, GA, deprecated, and archived. GA replaces production as the production-tier value. Transitions are owner-driven through pull requests; there is no enforced state machine.
• Add LIFECYCLE.md as the canonical reference: definitions, how to change lifecycle, the skill-to-pack ceiling rule (development < beta < GA), distribution and publication rules, and a pointer to catalog routing (APPENG-6026).
• Extend scripts/validate_lifecycle_ceiling.py so CI rejects unknown lifecycle values, ranks GA instead of production, keeps the ceiling rule (with deprecated and archived exempt), and emits a non-blocking warning when distribution: external is paired with lifecycle: development. This still runs from make validate-structure in the Tier 2 workflow.
• Point relationship-rules.md, the Compass manifest skill, and CLAUDE.md at LIFECYCLE.md.
• No manifest rename was required. A search of every YAML manifest found no spec.lifecycle: production. Existing components are development or beta.

Test plan

• make validate-lifecycle-ceiling — 28 unit tests passed
• make validate-structure passed
• Confirm the only lifecycle warning is non-blocking: network-policy-architect (distribution: external, lifecycle: development)
• Review LIFECYCLE.md as the owner-facing source for lifecycle changes