Module registry: add version lifecycle states with optional sunset date

“Mark version as bad” is informational only. Enterprise customers need a structured lifecycle so module authors can deprecate versions with a grace period and then block unsupported versions without maintaining brittle external OPA logic.

In many organizations, infrastructure patterns are encapsulated into approved modules (e.g., networking, S3 buckets, IAM roles, etc.). When these patterns are modularized, developers can safely self-serve infrastructure by consuming those modules rather than building resources directly.

Proposed solution
Add first-class lifecycle state for each module version:

• active

• deprecated (optional sunset_date)

• unsupported

Ideal behavior

• Using a deprecated version: plan succeeds but emits a warning stating it’s deprecated, recommended version, and sunset date (if set).

• Using an unsupported version: plan fails (hard stop).

Acceptance criteria

• Registry UI shows lifecycle state per version and (if applicable) sunset date.

• Lifecycle state is persisted per version and queryable via GraphQL.

• Deprecated usage generates a warning surfaced in the run.

• Unsupported usage blocks the run automatically.