wso2 module rollback: the store can already do it, the retention policy is what is missing

wso2 module rollback is published in docs/reference/commands.md and returns shell.unknown_command. Unlike the rest of #112's gap 2, what blocks it is not the command — it is a policy nobody has decided.

Split out of #112, which closed with this deliberately deferred.

The substrate already exists

The module store is version-addressed, and installing a new version does not disturb the old one:

• Store.VersionDir(namespace, version) — one immutable directory per version
• Store.ReceiptPath(namespace, version) — a receipt per version, not per module
• Store.ActivePath(namespace) — a pointer saying which one is live

An update writes a new version directory and moves the active pointer. The .replaced handling in internal/install/install.go is a within-install safety net for reinstalling the same version, not a cross-version prune. So previous versions appear to survive on disk already, and rolling back is close to writing the pointer and rechecking the receipt.

That claim is from reading the code, not from watching a live install. Confirm it first — install a module, update it, and look at the store — because the whole shape of this issue depends on it.

What actually has to be decided

How many versions are retained, and when is one reaped? Today nothing prunes, which is not a policy so much as an absence of one. A machine that tracks a fast channel accumulates every version it ever ran. The options are roughly: keep the previous one only; keep N; keep by age; keep until wso2 module remove. Each implies a different answer to "what can I roll back to", which is the question the command exists to answer.

What does rollback do to the version policy? architecture.md §7.4 says a rollback rechecks integrity, compatibility, and revocation, and that a revoked release is not a valid rollback target. If a user rolls back while following a channel, the next wso2 module update moves them straight forward again — so rollback either pins, or it is a temporary state the user is not told about. Pinning silently changes what a later module list reports. This wants deciding before it is built, not after.

What is rolled back to, when the user does not say? The previously active version is the obvious default, but only if retention guarantees it exists.

Acceptance criteria

• The retention question above is answered and recorded, in an ADR if it constrains the storage layout
• Whether rollback pins is decided and documented in the command reference
• wso2 module rollback <module> returns the module to its previous version and moves the active pointer
• A rollback target that is missing, or fails its receipt recheck, is refused with a typed problem that names what to do instead
• wso2 module list reports the post-rollback state truthfully, including the pin if rollback pins
• Retention is enforced somewhere, so the decision is real rather than documented

Start by confirming the versioned-store behavior with an install and update, then read Store.VersionDir, Store.ReceiptPath, Store.ActivePath, and the .replaced handling in internal/install/install.go. Review docs/architecture.md §7.4 and docs/reference/commands.md while resolving retention, pinning, and default-target policy; done means the documented decisions and all listed rollback, validation, listing, and retention criteria are covered.