Start forms: form-js (deployed) forms are not supported — mirror the TaskForm dispatch

[javahippie]

Summary

form-js forms (deployed forms, camunda-forms:/operaton-forms: form keys) work for task forms but are not supported as start forms. The start-process page has its own hand-rolled form pipeline that only understands embedded HTML forms (and, with the fix suggested in #90, server-rendered generated forms).

Current state — an avoidable asymmetry

Task side (src/components/TaskForm.jsx) has a clean three-way dispatch:

• formRef / camunda-forms: / operaton-forms: → CamundaForm component (form-js) via /task/{id}/deployed-form
• embedded: → EmbeddedHtmlTaskForm
• no form key → RenderedFallbackForm via /task/{id}/rendered-form

Start side (src/pages/StartProcessList.jsx) instead parses raw HTML with DOMParser in parse_form and knows nothing about form-js — a form-js start form ends in an "unsupported form type" message at best.

Suggested implementation

All building blocks already exist:

• CamundaForm component (schema rendering + submit wiring)
• get_deployed_start_form in src/api/resources/process_definition.js (GET /process-definition/{id}/deployed-start-form — returns the form-js schema for start forms, exactly like /task/{id}/deployed-form does for tasks)
• POST /process-definition/{id}/submit-form is already used by the start page

Mirror the TaskForm dispatch in StartProcessForm: check the start form key (from GET /process-definition/{id}/startForm), route form-js keys to CamundaForm fed by deployed-start-form, keep embedded/rendered handling for the rest. Mid-term this allows retiring the bespoke parse_form pipeline entirely so start and task forms share one implementation.

Note: the variable filtering from #92 (schema-bound keys only) must be applied here as well — start forms have no task scope yet, but withVariablesInReturn/initial variables handling has the same round-trip risk once initial data is loaded.