QA hardening: security RLS fixes, Flutter 3.47.5 upgrade, UI/validation fixes

Security — enforce write authorization server-side (was UI/RPC-only):
- it_service_requests RLS: block cross-office read/edit + self-approve (QA-015)
- pass_slips RLS: owner can complete but not self-approve (QA-046)
- swap_requests RLS: scope select/update to participants + admin (QA-047)
- storage: tighten it_service_attachments + task_attachments write/delete (QA-027)
- admin_user_management edge function: allow programmers to manage users (QA-016)

Fixes:
- workforce generator "uncovered shifts" false alarms (QA-043/044)
- network-map VLAN + New-location dialog validation, disabled-until-valid (QA-048)
- de-flake time-of-day-dependent dashboard metrics test (QA-045)

Toolchain:
- upgrade to Flutter 3.47.5 / Dart 3.13.4; font_awesome_flutter 11.0.0,
  flutter_quill 11.6.0, pdfrx 2.6.5; clear resulting deprecations (QA-002)

analyze clean; 139 tests pass; web build succeeds. Report + evidence in docs/qa/.

Note: also carries the in-progress Brick model cleanup already present in the
working tree. QA-001 (AI keys public in the build) is deferred by owner decision.

Co-Authored-By: claude-flow <ruv@ruv.net>

supabase/migrations/20260926090000_pass_slip_rls_hardening.sql

@@ -0,0 +1,38 @@
+-- QA-046: pass_slips self-approval bypass.
+--
+-- The original "pass_slips_update" policy (20260306090200_pass_slips.sql) is:
+--   FOR UPDATE USING (user_id = auth.uid()
+--                     OR profile.role IN ('admin','dispatcher'))
+-- with NO WITH CHECK. Postgres then reuses the USING expression as the
+-- WITH CHECK, so the row OWNER can PATCH their own pass slip to any values --
+-- including `status = 'approved'`, `approved_by`, `approved_at`. The approve/
+-- reject buttons are only gated in the UI, so any signed-in user could
+-- self-approve their own pass slip through the REST API (the same class of
+-- flaw as QA-015 on it_service_requests).
+--
+-- Intended behaviour (see pass_slip_provider.dart):
+--   * admin/dispatcher may approve/reject (and otherwise manage) any slip
+--   * the owner may only mark their OWN already-approved slip 'completed'
+--     (they return from the excusal); they must never set 'approved'/'rejected'.
+
+DROP POLICY IF EXISTS "pass_slips_update" ON pass_slips;
+CREATE POLICY "pass_slips_update" ON pass_slips FOR UPDATE TO authenticated
+USING (
+  -- Approvers can act on any slip.
+  EXISTS (
+    SELECT 1 FROM profiles p
+    WHERE p.id = auth.uid() AND p.role IN ('admin', 'dispatcher')
+  )
+  -- The owner may only touch their own slip once it is approved (to complete it).
+  OR (user_id = auth.uid() AND status = 'approved')
+)
+WITH CHECK (
+  EXISTS (
+    SELECT 1 FROM profiles p
+    WHERE p.id = auth.uid() AND p.role IN ('admin', 'dispatcher')
+  )
+  -- The owner's only allowed transition is approved -> completed. This blocks
+  -- self-approval: a pending slip's owner matches neither branch here, and the
+  -- USING clause above already refuses to expose a non-approved slip to them.
+  OR (user_id = auth.uid() AND status = 'completed')
+);