feat(canvas): per-workspace provision_timeout_ms override (#2054 phase 1)

[HongmingWang-Rabbit]

[Molecule-Platform-Evolvement-Manager]

Phase 1 of #2054 — build the canvas foundation that lets a workspace carry its own `provision_timeout_ms` from a server-side source (e.g. template manifest), so a slow runtime can declare its cold-boot expectation without a canvas release.

Today's gap

`ProvisioningTimeout.tsx:144` resolved the timeout via:
```ts
const base = timeoutMs ?? provisionTimeoutForRuntime(node.runtime);
```
`timeoutMs` was a single Props-level value that applied to all nodes — fine for tests but wrong for production where a batch can mix runtimes (hermes 12-min cold-boot alongside docker 2-min). The runtime profile fallback already handled per-runtime defaults; the missing layer was per-WORKSPACE override above that.

Fix (resolution priority, most specific wins)

1. `node.provisionTimeoutMs` — server-declared per-workspace override (this PR's new field)
2. `timeoutMs` prop — single-threshold test override
3. Runtime profile in `@/lib/runtimeProfiles`
4. `DEFAULT_RUNTIME_PROFILE`

Changes

File	What
`src/store/socket.ts`	`WorkspaceData.provision_timeout_ms?: number | null`
`src/store/canvas.ts`	`WorkspaceNodeData.provisionTimeoutMs?: number | null`
`src/store/canvas-topology.ts`	hydrate threads field onto `node.data`
`src/components/ProvisioningTimeout.tsx`	serialized-node string carries 4th positional field; resolver call passes `{provisionTimeoutMs: node.provisionTimeoutMs ?? timeoutMs}`
`src/components/tests/ProvisioningTimeout.test.tsx`	3 new tests

Tests (3 new — 19 total)

• hydrate carries `provision_timeout_ms` onto node data
• absent value hydrates to null + fall-through to runtime profile works
• server override wins over runtime profile via the resolver path the component actually uses

19/19 pass locally.

Phases

• Phase 1 (this PR): canvas foundation. Field plumbs through socket → node-data → resolver. Field is unused server-side until Phase 2 — pure infra, no behavior change today.
• Phase 2 (follow-up): `workspace-server` reads `provision_timeout_seconds` from template `config.yaml` at provision time, includes `provision_timeout_ms` in the workspace API/socket response.
• Phase 3 (template-repo PR): `template-hermes config.yaml` declares `provision_timeout_seconds: 720`; canvas `RUNTIME_PROFILES.hermes` becomes redundant + can be removed.

Test plan

• CI green
• No regression on hermes provisioning UX (still 12-min threshold via runtime profile fall-through, since no server data lands until Phase 2)