Refactor session-reading src/lib modules to take an explicit actor param instead of calling getSession() internally

Filed 2026-09-11 out of MARS-118's scope decision. NOT scheduled - no incident is driving it and no-speculative-work is in force this week. Filed so it is not silently dropped (No Deferral Without Permission). THE PROBLEM: several src/lib modules call getSession() INTERNALLY rather than taking the actor as a parameter - administrar-actions.ts (:166, :248, :1336, :1451, :1477), self-service-assignment.ts (:34), data-health-actions.ts, postgrado-actions.ts, estadisticas-email-actions.ts, rectificar-toast-actions.ts, edit-rules-ack-action.ts, profile-photo-request-action.ts among others (coder02-mars-cc's enumeration, 2026-09-11). getSession is cookie-bound (src/lib/auth.ts:193, React cache(), await cookies() at :203), so A FUNCTION THAT READS COOKIES CANNOT BE EXERCISED BY ANYTHING EXCEPT A BROWSER. That is the root cause behind MARS-118, not a symptom of it: it is why 12 of the 46 (protected) page.tsx files and every page whose reads route through those libs are unreachable from any self-check. THE FIX: take an explicit actor parameter; the route/action resolves the session at the HTTP boundary and passes it down. Standard shape - auth at the boundary, pure-ish functions below. WHAT THIS DOES AND DOES NOT BUY, and the second half is the part people get wrong. It makes those libs callable without a browser, so they become reachable from an internal self-check route and from unit tests. IT DOES NOT MAKE THEM CATCH THE PLUTO /informes CLASS: Mars has no local Postgres (commons forbids it), 9 test files vi.mock(@/lib/db), and .gitpush-pre.sh's typegen is 'next typegen' (Next route types) not 'supabase gen types' - so vitest exercises code paths, NEVER SQL validity against the live schema. B plus vitest would have passed straight through the incident that motivated MARS-118. I made exactly this error while scoping and withdrew it; do not re-derive it. SIZE: large, touches many call sites, and every touched lib is a behaviour-preserving refactor with no test that can prove it (see above). Needs its own plan and probably a staged sequence. Do not start without Elazar-level scheduling.