fix: count rb storage in telemetry and encode storage URIs - #161

The gap

rb storage is the first command with nested subCommands (list/ls) and
no top-level run. The usage-telemetry wrapper in src/main.ts only wrapped
each top-level command's run(), so rb storage list and rb storage ls
never emitted the cli_command usage event that every other command emits.

The fix

Moved the wrapper from main.ts into lib/telemetry.ts as instrumentCommands
and made it recurse through subCommands to any depth, instead of only
handling the top level. It is generic -- nothing in it is specific to
storage.

A nested command is named "parent child" in the existing telemetry
command property (e.g. "storage list"), the same words citty's own usage
line uses for it. No new schema field. A mid-level command with no run of
its own (like storage itself) still does not emit anything -- only a
resolved command that actually has a run gets wrapped.

The wrapper now takes an injectable capture function, defaulting to
captureCommand, the same DI pattern checkForUpdate already uses for
fetch. That's what makes it unit-testable without a network call or a real
telemetry key.

Related gap (reported, not fixed here)

Commands that terminate via process.exit() mid-run skip the wrapper's
finally, so no usage event flushes for that invocation. This is not a
one-off: process.exit() is the standing pattern across nearly every command
(ffmpeg, ffprobe, edit, generate, login, doctor, update, storage, whoami) for
success/error/cancellation exit codes -- dozens of call sites. Fixing it
properly means changing how every command signals its exit code instead of
calling process.exit() directly, which is a materially larger, riskier
change than this one and out of scope here.

Tests

Added src/__tests__/telemetry-instrumentation.test.ts, TDD'd against the
real citty runCommand dispatch (not a hand-rolled stand-in), covering:

• a top-level command's run is wrapped and captures once under its own name
• a nested subcommand captures once as "parent child"
• a parent with no run of its own does not capture
• a thrown error is captured as success: false and still rethrown
• recursion works at arbitrary depth with non-storage names, proving it
  isn't special-cased

pnpm test (272/272) and pnpm typecheck are green.

Storage URI encoding (Refs rendobar/rendobar#694)

An object key can hold %, ? or #. rb storage ls printed those raw
after storage://<id>/, which produced a URI a ? or # breaks in transit
and that parseStorageTarget could not always read back (a bare % not
followed by two hex digits throws in decodeURIComponent, and a literal ?
or # is rejected downstream).

Added encodeStoragePath to src/lib/storage-view.ts, matching the platform
contract in packages/shared/src/storage/refs.ts (rendobar/rendobar#696):
escape % first, then ?, then #, nothing else. formatListing now runs
every folder and key through it before building the printed
storage://<id>/<path> line. rb storage list --json and rb storage ls --json carry raw folders/key fields, not URIs, so they are unchanged.

parseStorageTarget now decodes a storage:// URI's folder part the same
way the platform does (decodeURIComponent, literal text if that throws),
so a URI copied from rb storage ls output browses the right folder again.
A bare <id>/<folder> typed by hand stays literal, since nothing encoded it.
--deliver is untouched -- it passes the user's text straight to the API,
which now decodes it on that side.

Covered by new tests in src/__tests__/storage-command.test.ts: the encoder,
the round trip through formatListing, and parseStorageTarget decoding a
storage:// URI while leaving a typed path literal.

BEGIN_COMMIT_OVERRIDE
fix: count rb storage list and ls in usage telemetry
fix: encode %, ? and # in rb storage URIs
END_COMMIT_OVERRIDE