refactor: [ENG-2925] rename `curate-html-direct` task type to `curate-tool-mode`

Mirrors `query-tool-mode` — both MCP and CLI already dispatch
`type: 'query-tool-mode'`, and the WebUI flattens it to `query` for
display. Curate now follows the same convention: both MCP
(`brv-curate-tool.ts`) and CLI (`continueSession`) dispatch
`type: 'curate-tool-mode'`, and the WebUI flatten in `task-status.ts`
maps it to `curate` (matching the pre-existing `query-tool-mode →
query` rule).

This converges the two tool-mode task types under a consistent
`<feature>-tool-mode` naming pattern. The legacy `'curate'` task type
(v1 LLM-driven curate executor in `agent-process.ts:616`) is left
untouched — deleting it would require ripping out the v1 curate-tool,
its 1860-line implementation, and ~2k LOC of tests; out of scope here.

Renamed files (git mv — pure rename):
- src/webui/features/tasks/utils/curate-html-direct.ts → curate-tool-mode.ts
- src/webui/features/tasks/components/curate-html-direct-sections.tsx →
    curate-tool-mode-sections.tsx
- test/unit/webui/features/tasks/utils/curate-html-direct.test.ts →
    curate-tool-mode.test.ts

Kept the function names (`isCurateHtmlDirectType`,
`parseCurateHtmlDirectInput`, `curateHtmlDirectRowTitle`,
`CurateHtmlDirectInputPayload`, etc.) — they describe the payload
shape (HTML envelope), not the task type, and renaming them would
balloon the diff without semantic gain.

Behavioural change: any MCP / CLI client on an older daemon (still
expecting `'curate-html-direct'`) will fail to dispatch — same binary
deploys, so non-issue in practice.

23 files, 71 ins / 71 del. Full test suite green (8382 passing).