AI harness: teach block schemas + validator about the app_config_selector input param

[07prajwal2000]

Why

#260 adds an app_config_selector custom block input param: a param whose value is an app config key, chosen by the caller, read from the block's JS with getConfig(params.<name>). It is the app-config half of the integration_selector from #259.

The AI harness enumerates the param types in two places, and neither knows about the new one. Until they do, the harness is a generation behind the portal on custom block authoring.

What

• apps/ai-gateway/src/harness/tools/getBlockSchemas.ts:26 — the switch (param.type) that turns a param into a TypeScript-ish type hint for the model. app_config_selector falls through to default: "any", so the model gets no signal that the value is a config key rather than the secret itself. It should read something like string // app config key, read with getConfig().
• apps/ai-gateway/src/harness/agents/sub-agents/blockBuilder/validator.ts:70 — validateCustomBlockField's switch. app_config_selector hits no case, so a generated block can put a boolean, an object, or an inline secret in that field and validation stays silent. It should validate as a string, alongside text_input / integration_selector.

Both are one-case additions. The value worth being deliberate about is the guidance: the model has to learn that this param holds a key and never a literal, or it will happily generate getConfig("my-actual-secret") — the exact failure the param type exists to prevent.

Notes

• Related to AI harness: add Custom Block Builder agent (parity with Route Config Agent) + inputParams/canvas sync #232: that issue asks for a Custom Block Builder agent that can author inputParams in the first place. This one is narrower — it only teaches the existing schema/validation path about a type that already exists. The two overlap in that a Custom Block Builder would need to know it can emit app_config_selector, which is worth folding in there rather than duplicating here.
• Runtime needs nothing: param: already resolves from the invocation and getConfig is already project-scoped.