feat: add workflow run settings amendment route for app parity

[william0wang]

Implements Item A + Item B of the workflow-parity backend requirements (zcode-acp-app/.zcode/docs/workflow-parity-backend-requirements.md).

Item A — amend-workflow-run-settings REST route

• POST /settings/workflow-runs/{runId}/settings?sessionId= (handler amendRunSettings in src/settings/workflow.ts, route in src/remote/settings-endpoint.ts) sends the v4 amendWorkflowRunSettings command via the same sendCommand path as resume; workId filled from the path segment.
• Three-state per field: absent = keep, null = revert to default, value = set (extracted by key presence, not through str()/num()).
• Empty delta → 422 unchanged with zero backend RPC; rejection tokens mapped per §2.2 (not_found 404 / not_configurable+unchanged+missing_boundaries 409 / model_unavailable+script_missing+compile_failed 422 / start_failed 502); capability absence keeps the generic mapping → 501, same as resumeWorkflowRun.
• Strict result guard: an accepted ack missing runId/toolCallId → 502 (the app needs them to re-point its run view after a supersede).
• Hub forwarding needs nothing — the existing per-instance /settings/* proxy covers the prefix; the route sits under the existing workflowRoutes capability gate.

Item B — pinned passthrough tests

• Conversation summary rows: all five parity fields (resumedFrom, supersededBy, subagentModel, maxConcurrency, concurrencyCeiling) survive v4/conversation/workflowRuns → GET /settings/workflow-runs untouched.
• History rows keep resumedFrom/supersededBy on GET /settings/workflows/runs.
• supersededBy invariant: never served without stopReason: "superseded" on both surfaces.

Deliberately out of scope (spec §2.3/§5): no startSavedWorkflow changes, no client work; the §3.1/§3.2 upstream schema extensions are separate (command already exists upstream — verified against ZCode 3.14.3).

Tests: 1801 passed (13 new), typecheck/lint/build green. feat → 0.49.0 minor.