fix: [ENG-2925] route CLI curate through daemon so it shows in Task queue

`brv curate <intent>` (tool-mode session protocol) wrote the topic file
in-process and bypassed the daemon's TaskRouter, so no TaskHistoryEntry
was ever persisted and the curate was invisible to the WebUI Tasks
panel — even though the MCP `brv-curate` tool already routed through
`curate-html-direct` and showed up. continueSession now dispatches the
same `curate-html-direct` task type as MCP; TaskRouter's lifecycle
hooks persist the entry automatically, so every CLI curate appears
under the existing `curate` filter (curate-html-direct already
flattens to `curate` in the WebUI). Free side effect: CLI curates
become cancellable from any surface the daemon supports.

Wire payload extended with optional `userIntent` so the row title
shows the user's prompt instead of the raw `<bv-topic>` JSON blob;
MCP omits the field and falls back to the bv-topic path attribute.
TaskInfo schema unchanged — the WebUI decodes userIntent at render
time via a helper that the list row and detail header both use.

Session state, retry-cap loop (MAX_ATTEMPTS=4), and SESSION_ID
path-traversal guard stay CLI-side. The in-process writeHtmlTopic /
curate-log / review-backup / sidecar-bump / index-regen block is
removed — daemon's case 'curate-html-direct' already does all of it.

Unit tests rewritten around a mock ITransportClient (capture the
`task:create` payload + simulate `task:completed`); new integration
test exercises a real TaskRouter + FileTaskHistoryStore round-trip
and asserts the entry surfaces in task:list with userIntent.