Decide what wso2 update means: the shell, the modules, or neither

wso2 update is published in docs/reference/commands.md and returns shell.unknown_command. Before anyone builds it, the word has to be given one meaning, because it currently has two and they are not the same job.

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

The ambiguity

Shell self-update. Replacing the wso2 binary itself with a newer release. Nothing in the CLI does this today; scripts/install.sh and install.ps1 do it from outside. It is the harder of the two: a running process replacing its own executable is platform-specific, and on Windows the file is locked while it runs, so the usual answer is to stage the replacement and hand off to a helper.

Module update. Already exists and already works, as wso2 module update [--all], with progress reporting and --yes/--dry-run confirmation as of #134.

A user typing wso2 update on a machine with modules installed could reasonably expect either, or both.

What to decide

1. Does wso2 update mean the shell, everything, or nothing? "Everything" is the friendliest and the most surprising — it would update the shell and every module in one command, which is a lot to do without being asked precisely. "The shell" is the narrow reading and makes wso2 update and wso2 module update a clean pair. "Nothing" — leaving the word unbuilt and removing it from the reference — is also a legitimate answer, and cheaper than the other two.

2. If it updates the shell, how? Where the new binary comes from (the same release channel the install script uses), how its integrity is established, how the running executable is replaced on each supported platform, and what happens to installed modules whose declared shell compatibility the new version breaks — the shell already refuses an incompatible module at launch, so an update can strand one.

3. Does it interact with the compatibility window? wso2 version already reports shell, protocol, and module versions. An update that moves the protocol version can invalidate installed modules, and the command should say so before acting rather than after.

Why this is its own issue

#112 listed wso2 update among nineteen unbuilt commands as though it were the same size as wso2 whoami. It is not: whoami reads state, and this rewrites the program that is running. It also touches the install scripts, which are the one part of the distribution the acceptance suite drives end to end on both Unix and Windows.

Acceptance criteria

• wso2 update's meaning is decided and recorded in the command reference
• If it is not built, the word is removed from the reference rather than left published and unimplemented
• If it is built: the replacement strategy is documented per platform, including Windows
• If it is built: an update that would strand an installed module on protocol incompatibility says so before acting

Start with docs/reference/commands.md, scripts/install.sh, install.ps1, and the existing wso2 module update and wso2 version behavior. Determine and document whether wso2 update is built or removed, including platform replacement details and any protocol-compatibility warning required before action.