wso2 module info and wso2 module verify: answer from state the shell already keeps

Two of the commands docs/reference/commands.md publishes return shell.unknown_command, and both are answerable entirely from state the shell already keeps. They are grouped because they read the same three sources and would otherwise duplicate that reading.

Split out of #112, which closed with nine of gap 2's nineteen commands built. This is the part of the remainder that nothing blocks.

wso2 module info <module>

What a user asks after wso2 module list shows something surprising. Everything it needs already exists:

• the installed version, from the active pointer (Store.ReadActive)
• the receipt for that version (Store.ReceiptPath), which records what was installed and what it was checked against
• the version policy (policy.json) — the followed channel, and the pin if there is one
• what the catalog publishes on that channel, which Installer.Check already fetches in one request

wso2 module list already joins the same sources for its table; this is the single-module long form.

Worth deciding while specifying it: whether it reaches the network at all. A --offline reading answers "what is on this machine" from the store alone and cannot fail on a catalog outage; the connected reading also answers "and what could it be". module list always reaches out, so the default should probably match it.

wso2 module verify <module>

Answers "is what is installed still what was installed". The check already exists and runs on every launch — the shell rechecks the installed executable against its receipt before dispatching to it. This surfaces it on demand rather than only as a launch-time refusal.

What it must not claim: a digest match proves the artifact is the one the catalog entry described. It does not prove the entry is authentic, because nothing signs the catalog (architecture.md §9.2). The output should say what was checked in those terms rather than the word "verified" unqualified, which reads as a signature claim the shell cannot make. #80 is what would change that.

Acceptance criteria

• wso2 module info <module> reports the installed version, the followed channel, the pin if any, the digest the receipt records, and what the catalog publishes for it
• It refuses an uninstalled namespace with a typed problem naming wso2 module available
• wso2 module verify <module> rechecks the installed executable against its receipt and reports the outcome
• A tampered executable is reported as a mismatch, and that case is covered by a test that actually mutates the file
• Neither command's output claims a signature guarantee; both describe integrity checking in §9.2's terms
• Both honour --output table|json per ADR 0003

Start with the existing wso2 module list implementation and the launch-time receipt check, tracing Store.ReadActive, Store.ReceiptPath, policy.json, and Installer.Check. Read docs/reference/commands.md, docs/architecture.md §9.2, and ADR 0003 before settling the output and offline behavior. Done means both commands report the specified state, formats, and integrity outcome, including a test that mutates an executable.