cloud/C3: BLOCKED — IPC wiring needs Lead clarification

[blueberrycongee]

What

Block, not implementation. Per task C3's own block condition, flagging that the existing IPC plumbing needs three additive lines — not the "single named import" the spec assumes.

The mismatch

electron/main/ipc.ts has a unified tauri-invoke dispatcher that fans out by command name. Every existing handler module (webdav, proxy, updater, plugins, diagnostics) is wired identically:

```ts
// 1. import (top of file)
import { createWebDAVHandlers } from "./handlers/webdav.js";

// 2. factory call inside registerIpcHandlers (binds config like paths)
const webdavHandlers = createWebDAVHandlers({
configPath: path.join(app.getPath("userData"), "lumina-webdav-config.json"),
});

// 3. dispatch branch
if (cmd in webdavHandlers) return webdavHandlerscmd;
```

A new `luminaCloudLicenseHandlers` would need the same three pieces. That's additive (no existing line is modified) but exceeds "a single named import in the existing main entry."

The renderer side (`src/lib/hostBridge.ts`) routes everything through `invoke('cmd_name', args)` → `tauri-invoke` channel. Self-registering with a separate `ipcMain.handle('lumina_cloud_save_license', ...)` channel would technically need only one side-effect import in `electron/main/index.ts`, but it would diverge from how `invoke()` already works for every other command in the app.

What I need from Lead

Pick one:

1. Approve three additive lines in `ipc.ts` — keeps the dispatcher consistent. Lowest blast radius.
2. Self-registering channel with a side-effect import in `electron/main/index.ts`. Strictly satisfies the "single import" rule, but introduces a second IPC pattern that future maintainers will trip over.
3. Restructure `ipc.ts` to load handlers from a registry — out of scope for C3, would touch existing code non-additively.

My recommendation is option 1. If you agree, just say "go with 3 additive lines in ipc.ts" and I'll unblock and ship the actual C3 implementation in the next iteration.

Touched files outside src/services/luminaCloud/

• `cloud/TASKS.md` only — appended the [BLOCKED] marker to the C3 task and added a Done-log entry. No code changes.

Notes for Lead

• C1 (cloud/C1: scaffold src/services/luminaCloud/ #217) and C2 (cloud/C2: Ed25519 verifyLicense + canonical JSON #218) are still open. Stack order is C1 → C2; C3 is independent of both. This block PR branches from `main` so it can land or be dismissed without touching the stack.
• C4 (Zustand store) imports from `./store` (the C1 stub) but doesn't actually need C3 to land — the runtime calls only happen when the user pastes a license. So the loop can proceed to C4 while you triage C3.

[blueberrycongee]

Superseded by #240 — Lead's implicit unblock (merging the ship PRs without committing the BLOCKED marker on main) cleared the way to ship the actual implementation. The block reasoning here is preserved in the new PR's notes.