plugins: define revocation and publisher compromise handling

[puremachinery]

Problem

Plugin signature verification establishes provenance, but provenance is not revocation. If a publisher key is compromised or a signed plugin later becomes known-malicious, Carapace needs a clear startup/update behavior and operator recovery path.

Goal

Define and implement a practical revocation model for signed plugins and publisher keys.

Acceptance criteria

• Document the current trust model as Ed25519 trusted publishers unless a separate transparency-log workflow is explicitly implemented later.
• Document that transparency-log monitoring is out of scope for this issue.
• Add a local revocation list format that can revoke publisher keys and plugin artifact digests.
• On startup and plugin update, revoked plugins are disabled before execution.
• Operators get a clear warning that names the plugin id, revocation reason, and recovery action without printing secrets or unsafe paths.
• Define publisher key compromise handling: key rotation, grace behavior, and how already-installed plugins signed by the compromised key are treated.
• Add tests for revoked digest, revoked publisher key, missing revocation list, malformed revocation list, and clean plugin startup.
• Update plugin development/security docs with the limitation that signatures prove provenance but do not prove benign behavior.