Banned window.confirm() shipped in friend-requests + blocked pages (duplicates the themed data-confirm modal)

Area: Account (re-run) (audit p1r) · Surface: /friends/requests, /friends/blocked · Dimension: native-dialog · Severity: major

The Engineering Law bans native confirm()/alert()/prompt() (they break theme and look like malware). These two account/identity templates put data-confirm on the <form> element, which the global app.js handler and mobile-v2.js interceptor already turn into a themed App.modal.confirm. But each template ALSO registers a redundant inline submit handler that calls window.confirm() directly. The result is a banned native dialog (at minimum on keyboard-Enter submission, and a double-confirm risk) on the Cancel-friend-request and Unblock flows. Every other account/identity template (drafts, scheduled, rss, sessions, verification cancel, friends.php unfriend) correctly relies on the global data-confirm handler with no inline window.confirm.

Evidence

platform/templates/profile/friend-requests.php:146-152 and platform/templates/profile/blocked.php:63-69 both ship: `document.querySelectorAll('form[data-confirm]').forEach(function(f){ f.addEventListener('submit', function(e){ var m = f.getAttribute('data-confirm'); if (m && !window.confirm(m)) e.preventDefault(); }); });`. Meanwhile app.js:1367-1383 already binds a GLOBAL `[data-confirm]` click handler that calls `App.modal.confirm(...)`, and mobile-v2.js:94-96 has its own interceptor whose own comment says "never window.confirm — banned". So these two templates fire the BANNED native dialog (on Enter-key submit) on top of the themed modal.

Suggested fix. Delete the inline <script> blocks at friend-requests.php:146-153 and blocked.php:63-70 entirely. The global app.js [data-confirm] handler (and mobile-v2.js) already render the themed confirmation modal for these forms — no per-page script is needed.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.