feat: add lk update and lk can-update, and point unknown commands at them

[u9g]

lk update works out how the running lk was installed and runs that installer's upgrade, so docs and starter templates (e.g. livekit-examples/agent-starter-python#105) can say "run lk update" instead of listing a command per platform.

Detection is by the resolved path of the running binary:

Installed via	Path contains	Runs
Homebrew (macOS / Linuxbrew)	/Cellar/livekit-cli/	brew upgrade livekit-cli
winget	\WinGet\Packages\LiveKit.LiveKitCLI	winget upgrade --id LiveKit.LiveKitCLI --exact
install-cli.sh (Linux)	exactly /usr/local/bin/lk	curl -sSL https://get.livekit.io/cli | bash

Anything else (go install, a local build) exits non-zero and points at the install docs rather than guessing.

lk can-update asks GitHub for the latest release and prints Yes (with the newer version and a pointer to lk update) or No.

An unknown command or subcommand (e.g. lk agent frobnicate) keeps urfave/cli's No help topic for '…' message and exit code 3, and adds: "If this command is new, your lk may be out of date. Run lk can-update to check and lk update to update." A coding agent that follows docs written for a newer lk then learns how to fix it.

Testing

• TestUpdateCommandFor covers each mapping and the unknown cases.
• Ran a build from a Homebrew-style Cellar path on macOS: it ran brew upgrade livekit-cli and upgraded 2.18.4 → 2.18.8.
• lk can-update prints No on 2.18.8 and Yes on a build with Version set to 2.18.4.
• lk frobnicate, lk agent frobnicate and lk docs serch print the hint and exit 3.

[u9g]

An unknown command (now suggests lk can-update and lk update), lk can-update on the latest release (no) and on an older build (yes), then lk update from a Homebrew Cellar install (runs brew upgrade livekit-cli) and from a local build (refuses and points at the install docs).

lk-update.mp4

[bcherry]

should there be a way to check if you have the latest version too?