fix: [ENG-2884] disclose v1-stub status on dream sessions/cancel

Both subcommands are intentional v1 placeholders — the daemon doesn't
persist session state, so dream sessions always returns [] and dream
cancel is a no-op. The previous surface advertised them as if they
were functional: descriptions said 'List active...' / 'Discard a...',
JSON envelopes returned success-looking shapes ({sessions: [], status:
ok} / {status: cancelled}), and machine-readable consumers that
branched on the response had no way to know the daemon was never
consulted.

This is a cheap-honesty fix, not a real persistence implementation.
Real persistence is a separate ticket.

Changes:
- DreamSessions.description prefixed with '[v1 stub]' and now names
  the stateless behavior inline.
- DreamCancel.description prefixed with '[v1 stub]' and now names the
  no-op behavior inline.
- Both JSON envelopes gain a 'note' field disclosing v1 status so
  machine consumers see the caveat at the same key they'd branch on.
- Topic-root listing in brv dream's run() body flags both subcommands
  as '[v1 stub]' in the one-liner hint.

4 tests in test/commands/dream.test.ts cover: each static description
contains 'v1 stub'; each --format json envelope's data.note discloses
stateless / no-op semantics.