refactor(sse): guard the KIE task-id and callback-url reads at their source

[backryun]

Part of the TS7 readiness campaign (#8484). One root cause, 5 diagnostics, zero new.

Root cause

kieExecutor.createTask() returns JsonObject — i.e. Record<string, unknown> — so createData.data is unknown. Three handlers each carried the same unguarded read verbatim:

const taskId = createData?.data?.taskId || createData?.taskId;

open-sse/utils/kieTask.ts already holds two helpers with exactly this shape: normalizeKieTaskState() and parseKieResultJson() both take unknown, guard with isJsonObject(), and return a declared type. normalizeKieTaskState() even does the identical record.data dance. So this fixes the read at its source rather than at each of the three call sites, following the neighbour rather than inventing a third idiom.

Separately, getKieCallbackUrl() took KieCallbackBody — a weak type (every property optional). Passing a request body whose declared keys are prompt / timeout_ms / poll_interval_ms shares no property with it, which is TS2559 at both music call sites. The function receives arbitrary upstream request bodies, so it now takes unknown and guards the same way its neighbours do. KieCallbackBody had no other reference in the repo and is removed.

Diagnostics fixed

file	count	code
open-sse/handlers/imageGeneration.ts	1	TS2339 taskId on unknown
open-sse/handlers/videoGeneration.ts	1	TS2339 taskId on unknown
open-sse/handlers/musicGeneration.ts	3	1x TS2339 + 2x TS2559 KieCallbackBody

Measured as a line-number-agnostic diff of the complete tsc -p open-sse/tsconfig.json error set against a freshly re-measured base: 208 → 203, 5 fixed, 0 new. Also verified on top of the eight other open TS7 slices (160 → 155), where it applies without conflict.

Behaviour is unchanged

• isJsonObject() rejects arrays and null in exactly the positions where optional chaining already produced undefined, so the fallback to a top-level taskId is reached in the same cases.
• The callers' String(taskId) coercion moved inside the helper, so a numeric id still reaches pollTask() as a string.
• A falsy id ("", 0, missing) still returns nothing and still takes the handlers' 502 branch.
• getKieCallbackUrl() only widens what it accepts; the three key casings, the blank-string rejection and the configured-URL fallback are untouched.

Test plan

New tests/unit/kie-task-helpers.test.ts — 10 tests covering every arm of the two helpers, including the ones the old inline expression never had coverage for:

• nested data.taskId, top-level fallback, nested-wins-over-top-level
• numeric id coercion
• non-object data (string / array / null) still falling through to the top level
• falsy ids ("", 0) treated as absent, preserving the !taskId guard
• non-object response (null, undefined, a string)
• all three callback-url casings, blank-string rejection, and the fallback for {} / no-arg / non-object bodies

node --import tsx/esm --test tests/unit/kie-task-helpers.test.ts   # 10/10

Regression run over the handlers this touches — kie-executor-routing, image-generation-handler, image-generation-route, music-generation-handler, google-flow-video-4569, video-deepinfra-6653, alibaba-video-media, new-content-providers, audio-speech-handler, audio-transcription-handler, comfyui-baseurl-override-6928: 182 pass, 0 fail.

Gates: typecheck:core clean, check:file-size OK, check:known-symbols OK, ESLint clean on the touched files (the two no-explicit-any reports in musicGeneration.ts / videoGeneration.ts are the pre-existing catch (err: any) entries already frozen at count 1 each in eslint-suppressions.json; this PR adds none).

The one red check, Merge integrity (changelog + generated skills), is base-red on release/v3.8.49 and unrelated to this diff — it reproduces on the bare tip and is being fixed by #8657 / tracked in #8658.