AI harness: add Custom Block Builder agent (parity with Route Config Agent) + inputParams/canvas sync

[07prajwal2000]

Problem

The AI harness has a Route Config Agent (creates/modifies route settings) paired with the Block Builder Agent (creates/modifies canvas logic for that route). Custom blocks have no equivalent settings agent:

• The harness cannot create a new custom block at all — it just emits a :createCustomBlock{label="..."} chip telling the human to create one manually (apps/ai-gateway/.../summarizer.ts:184).
• Block Builder Agent CAN edit an existing custom block's canvas (targetType: "custom_block"), but nothing sets or updates the custom block's own metadata (name, description, inputParams).

Gap: inputParams drifts from canvas

Custom blocks declare inputParams (custom_blocks_list.input_params, jsonb) independently of their canvas. When the harness edits a custom block's canvas via fluxify.ops.canvas, nothing reconciles the two:

• The agent can wire canvas logic that reads a param never declared in inputParams.
• A declared param can go unused by the canvas.
• No validation catches either case, on the harness or server side.

Ask

Add a Custom Block Builder Agent, mirroring the existing Route Config Agent (apps/ai-gateway/src/harness/agents/sub-agents/):

• Creates new custom blocks (name, description, inputParams) via a new ops path (fluxify.ops.custom_block's create action already exists server-side — opsClient.ts just never calls it).
• Modifies an existing custom block's inputParams/metadata when the paired Block Builder Agent canvas edit adds/removes params the canvas reads.
• Should run in the same create-then-canvas order as routes (settings agent first, block builder second), so the custom block exists before its canvas is authored.

Reference

Investigated as a follow-up to the recent route/custom-block canvas duplicate-merge hardening (saveCanvas's mergeAiDuplicates, normalize.ts singleton remap) — that logic is already parent-type agnostic and needs no changes for this. This issue is purely about the missing settings-agent parity and the inputParams sync gap.

[07prajwal2000]

Filed #261, which overlaps with the inputParams half of this issue.

Context: #260 adds an app_config_selector input param type — a param carrying an app config key, picked by the caller, read as getConfig(params.<name>). The portal side is implemented, but the harness enumerates the param types in two places that don't know about it:

• apps/ai-gateway/src/harness/tools/getBlockSchemas.ts:26 — falls through to default: "any", so the model gets no hint the value is a key and not the secret.
• apps/ai-gateway/src/harness/agents/sub-agents/blockBuilder/validator.ts:70 — no case, so nothing catches a generated block that inlines a literal secret there.

Why it matters here: the Custom Block Builder Agent this issue asks for is the thing that would emit inputParams, so it needs to know app_config_selector exists and what it means. #261 only covers the read path (schema hint + validation) for params that already exist. If this issue lands first, the emit-side guidance belongs in it and #261 shrinks to two switch cases; if #261 lands first, this issue inherits a validator that already understands the type.

Worth deciding which way round before either is picked up.