-- platform_library_book_schools is written by the Team Portal, which
-- operates across many schools at once (supplying one book to several
-- schools in a single action) — it never runs inside a single school's
-- tenant context the way withTenant() provides. RLS scoped to
-- app.current_school_id can never be satisfied by that kind of write,
-- confirmed directly: an insert exactly matching what the Team Portal
-- route performs fails with "new row violates row-level security
-- policy" every single time, regardless of the data being otherwise
-- completely valid.
--
-- This isn't a security gap — the actual protection for this table was
-- always the application layer, not RLS: every school-scoped read of
-- it (in content.js and library.js) already filters with an explicit
-- WHERE school_id = $1 using the authenticated school from withTenant,
-- and every write to it happens through Team-Portal-only,
-- platform_admin-gated routes. RLS was a second, well-intentioned but
-- wrongly-scoped layer that ended up blocking the table's only writer
-- rather than protecting it.
ALTER TABLE platform_library_book_schools NO FORCE ROW LEVEL SECURITY;
ALTER TABLE platform_library_book_schools DISABLE ROW LEVEL SECURITY;

-- library_book_availability is NOT touched here — it's written by
-- School Admin routes that correctly run inside withTenant(), so RLS
-- on it continues to work exactly as intended.