wso2 module install accepts a module whose declared shell range this shell does not satisfy

Found driving the first real release end to end: the released shell v0.0.1, the released module reference/v0.1.0, and a clean WSO2_HOME.

Problem

Installing succeeds. Running fails.

$ wso2 module install reference
Installed reference v0.1.0 for darwin/arm64.
The artifact was checked against the digest the catalog publishes. Artifacts are integrity-checked, not signed.
exit=0

$ wso2 module list
MODULE      INSTALLED   CHANNEL   UPDATE
reference   v0.1.0      stable    current

Every installed module is current.

$ wso2 reference --help
error: the "reference" module requires a WSO2 CLI shell matching ">=0.1.0 <2.0.0", and this shell is 0.0.1 (modules.incompatible_shell)
  Update the module or the WSO2 CLI so the shell version is supported.
exit=69

modules/reference/module.json declares "shell": ">=0.1.0 <2.0.0", and 0.0.1 does not satisfy it. The check exists and works — it just runs at launch, after the module is on the machine and reported as current.

Why it happens

Catalog selection refuses a version whose protocol the shell cannot speak — incompatibleProtocol, internal/catalog/select.go:74. It does not apply the same reasoning to the manifest's compatibility.shell range, so a version the shell provably cannot launch is still selectable.

The two halves of compatibility are therefore enforced in different places and at different times: protocolVersions before installing, shell at first invocation.

Why it matters

This is the first command a new user runs after installing the CLI. They are told the install succeeded, wso2 module list calls it current, and the failure appears only when they try to use it — with a recovery line ("Update the module or the WSO2 CLI") that cannot be acted on from where they are, because the catalog publishes no other version.

wso2 module list naming it current is the sharpest part: a module the shell cannot launch is reported as being in good standing.

Acceptance criteria

• wso2 module install <module> refuses a version whose declared shell range this shell does not satisfy, naming the range and the shell version, before anything is written
• The refusal is distinguishable from the protocol refusal, since the remedies differ
• When the catalog publishes an older version this shell does satisfy, selection picks it rather than refusing outright — same shape as the protocol path
• wso2 module list does not report a module the shell cannot launch as current
• A test installs against a shell version outside the declared range and pins the refusal

Refs the release this was found in: shell v0.0.1, reference/v0.1.0.

Start at internal/catalog/select.go:74 and trace the wso2 module install and module list paths, comparing the existing protocol compatibility selection with the manifest shell-range check. Use modules/reference/module.json and the release versions in the report as fixtures. Done means incompatible shell versions are rejected before writes, compatible older versions can be selected, and module list does not call an unlaunchable module current; add the described installation test.