chore(web): sync batch job launcher params with tigerflow-ml 0.2.0

[cswaney]

Summary

Closes the drift between `NewJobModal`'s task schemas and the `Params` classes shipped in tigerflow-ml 0.2.0. `transcribe` and `detect` are already in sync; this covers the three tasks with gaps.

• ocr: expose `json_schema` (gated on the JSON output format) and `buffer_size` (multi-page PDF only).
• translate: expose `max_model_len` for models with larger context windows than the default `chunk_size * 2.5 + 512` formula.
• chat: 0.2.0 accepts images, audio, and video alongside text. Widen `inputExtOptions` accordingly and add `max_image_pixels`, `audio_sampling_rate`, `video_sample_fps`, and `response_schema`. Media params are modality-gated so the modal only shows what applies to the selected input.

Two new gates in `isParamVisible` — `imageOnly` and `audioOnly` — mirror the existing `videoOnly`.

Notes on the free-form JSON textareas

`json_schema` (ocr) and `response_schema` (chat) are not validated client-side. tigerflow-ml's `parse_kwargs` accepts both JSON and Python-literal dict syntax, and `chat.response_schema` uses a `=` format where `` can be JSON, a list, a regex, or a grammar. A strict `JSON.parse` would reject inputs the help text explicitly advertises. Malformed input surfaces as a clear tigerflow-ml error at task setup.

Test plan

• `npm run lint`
• `npm test` (556 pass; +4 new — imageOnly x2, audioOnly x2)
• Manual: launch a chat job on Della with an image input; confirm `max_image_pixels` is shown and audio/video params are hidden.
• Manual: launch an ocr job with JSON output and a schema; confirm the schema flows to tigerflow.

Notes

• No backend change. `BatchJobRequest.params` is a passthrough dict, and tigerflow-ml validates and defaults each param.
• Sub-task of Update container versions #451.

Closes #513

[claude]

Review

Solid, well-scoped PR - the new params are wired through all three call sites (render, validation, submit) via the existing isParamVisible predicate, and the two new gates (imageOnly, audioOnly) follow the established videoOnly/multiPageOnly pattern closely. The showWhenParam reuse for json_schema mirrors detect's existing pattern instead of inventing a new mechanism. Comments are updated in the right places (the multi-line doc comment above isParamVisible, the stale "image inputs deferred" comment on chat).

Nit: dead entries in IMAGE_INPUT_EXTS / AUDIO_INPUT_EXTS

IMAGE_INPUT_EXTS includes .webp, .gif, .bmp and AUDIO_INPUT_EXTS includes .m4a, .ogg, but chat.inputExtOptions (the only source of inputExt, via the Listbox around line 1516) doesn't expose any of these. Since inputExt can only ever be one of the dropdown's values, these five entries in the two Sets are currently unreachable for gating purposes.

Not a functional bug - isParamVisible still behaves correctly for every reachable value - but it reads as if those formats are supported by the modal's chat task when they aren't (yet). Two options:

• Trim the sets down to exactly what chat.inputExtOptions offers, or
• Add the missing options to chat.inputExtOptions if tigerflow-ml's chat task actually accepts .webp/.gif/.bmp/.m4a/.ogg (plausible, given the PR only adds a subset of common extensions).

Either is a one-line fix; flagging since it's the kind of inconsistency that's easy to trip over later when this pattern gets extended and copied from here.

Test coverage

Good use of the existing isParamVisible test suites as a template for the two new gates (imageOnly x2, audioOnly x2). The chat "multimodal" registration test was cleanly converted rather than left partially describing old behavior. json_schema's showWhenParam gate and buffer_size's multiPageOnly gate don't get dedicated tests, but that's reasonable since the underlying predicate branches are already covered generically (isParamVisible - showWhenParam, isParamVisible - multiPageOnly describe blocks), so this isn't a gap so much as appropriate reuse of existing coverage.

Everything else

• No backend changes needed, confirmed by reading how params flows through to BatchJobRequest - correct call-out in the PR description.
• The decision not to JSON.parse-validate json_schema/response_schema client-side is well justified (tigerflow-ml's parser accepts non-JSON Python-literal/"=" syntax too) and clearly documented in both the PR description and the field's help text, so users aren't left guessing why validation is absent.
• max_model_len and response_schema are plain optional fields with no gating needed - appropriately left ungated given translate/chat's task shapes.
• Minor style note: response_schema's placeholder duplicates a fairly long JSON literal already present in its own help text - purely cosmetic, not blocking.

No correctness, security, or performance concerns found. Nice, tightly scoped change.