[kvlonge]

Why

The jobs and triggers pages in the web UI still ran on mock data. People need to see a target's published jobs and triggers, launch a job, and pause, resume or reset triggers from the live control API.

Changes

• New read endpoint GET /api/control/locations/{location_id}/targets/{target}/jobs (listPersonJobs). It returns each published job or group with its description, resolved selection and concurrency groups. It is authorized like the trigger listing, and job settings are not returned.
• The UI client wires listJobs, getJob, launchJob, listTriggers, getTrigger, setTriggerStates, resetTriggerToDefault and resetSensorCursor. Writes send the CSRF header and a default reason, and the server records the session actor.
• View fields the server does not report are now nullable, and pages hide the widgets they would feed instead of showing placeholders. Full refresh stays hidden because job run requests do not support it.
• Jobs and triggers pages refresh on the ticks and snapshot topics, so trigger toggles update live.
• Regenerated the TypeScript client schema.
• A group trigger's last run is its group run, not a child run. A bulk pause or resume that fails partway says how many triggers already changed.

Known follow-up: the jobs page makes one ticks request per trigger on every refresh, so its request count grows with the number of triggers.

DuckShop: not applicable. This adds a control API read and UI wiring; no project shape, data value or lifecycle sequence changes.

Verification

• cargo test -p sqlbuild-orchestration --lib -- api:: declarations:: on SQLite and PostgreSQL, including the per-role jobs listing and the denial matrix.
• UI: svelte-check 0 errors, vitest 54/54, production build.
• Live sqb server session: jobs list, pause and resume, run now, job detail, triggers list, schedule detail, reset to default and sensor cursor reset, confirmed in the security audit log.
• make check-ci and the public-repository scan.