fix(forms): prevent stored XSS in admin submissions view and render it in the admin layout

[josevenceslau]

Problem

GET /admin/forms/:id/submissions (packages/core/src/routes/admin-forms.ts) builds a bare HTML page and interpolates submission_data — public, user-supplied form input — straight into the page:

<td><pre>${JSON.stringify(JSON.parse(sub.submission_data), null, 2)}</pre></td>

This is an unescaped sink. A visitor can submit a form field containing markup/script (e.g. a message value of <img src=x onerror=…> or <script>…</script>), and it then executes in the admin's browser when they open the submissions list — a stored XSS in the admin UI, reachable by any anonymous form submitter. The page is also unstyled (a standalone <!DOCTYPE html> with inline CSS, no admin chrome), unlike every other admin forms page.

Fix

• Moves the page into a dedicated template, admin-forms-submissions.template.ts, rendered inside the Catalyst admin layout via renderTable — consistent with admin-forms-list.template.ts and the rest of the admin.
• Escapes every key and value of submission_data (and the form display name) through the existing escapeHtml util. Non-JSON submission_data falls back to an escaped raw string.
• Surfaces the submission_number and status columns that were already stored but never displayed.

The route handler now just calls the template (net −34 lines).

Tests

src/__tests__/templates/admin-forms-submissions.test.ts (4 tests):

• escaping of <script> / <img onerror> / attribute payloads in values, keys, and the form name;
• the non-JSON submission_data fallback;
• the empty state;
• the chromed render (layout + heading + count).

tsc --noEmit and ESLint pass; no existing tests reference the old page.

Notes

No existing issue tracked this — happy to file one to link if the maintainers prefer. I have a follow-up (submission status workflow, delete, filters/search, audit) built on top of this in a downstream project; glad to open it as a separate feature PR if there's interest.