feat: complete the standard Skill package lifecycle

[Teingi]

Feature description

Add a governed lifecycle for standard Agent Skill packages, from exact package capture and review through Library discovery, local or remote publication, observed use, revision, deprecation, retirement, and safe unpublication.

A managed Skill revision should own one immutable package rooted at SKILL.md, including admissible scripts/, references/, assets/, licenses, and other package files. The exact approved bytes—not a regenerated instruction-only approximation—should be what compatible coding agents receive.

Problem and proposed solution

PowerContext already governs Skill metadata and revisions, but the current lifecycle is incomplete for real Agent Skill packages:

• exact multi-file packages can lose scripts or references during import;
• approval does not by itself provide an explicit, drift-safe delivery path;
• Codex and Claude Code targets need the same reviewed package while retaining agent-specific installation locations and host policies;
• remote machines need secure pull-based convergence and receipts without giving the Server SSH or arbitrary filesystem authority;
• deprecation, retirement, usage evidence, and safe unpublication must remain distinct from immutable revision history.

Implement the lifecycle specified by the Standard Skill Package Lifecycle RFC with these acceptance criteria:

• Capture, validate, store, download, and diff a complete bounded package with a stable manifest and content digest.
• Approve immutable Skill revisions and expose only eligible current heads through Library search and governance workflows.
• Publish the same approved bytes explicitly to project-scoped Codex and Claude Code targets, with compatibility assessment, ownership checkpoints, drift/conflict detection, update, and safe unpublication.
• Support credential-bound remote Receiver enrollment and pull reconciliation over HTTPS by default, including desired generations, package verification, atomic installation, revocation, and bounded delivery receipts.
• Keep package requirements separate from runtime authority; review or publication must not grant tool, network, filesystem, secret, or dependency-install permissions.
• Preserve lifecycle-specific API errors so clients can distinguish a deprecated or retired Skill from an invalid target state.
• Cover the public API, persistence migrations, CLI/Dashboard workflows, English and Chinese documentation, and focused plus end-to-end tests.

Alternatives considered

• Publishing only a generated SKILL.md is insufficient because it does not preserve the package that was reviewed.
• Server-side SSH or arbitrary remote-path writes create an unnecessarily broad trust boundary and provide weak delivery evidence.
• Automatically publishing every approved Skill would enlarge each Agent's working set and make conflicts or stale content harder to govern.
• Rewriting packages per target would make the delivered bytes diverge from the approved artifact.

Additional context

• Initial implementation and validation: feat(skill): add standard package lifecycle and remote distribution #1351

• English RFC: docs/en/rfcs/1351_standard_skill_package_lifecycle.md

• Chinese RFC: docs/zh/rfcs/1351_standard_skill_package_lifecycle.md

• I am willing to contribute code, docs, or design feedback.