bedel can write: updateImageRotation reachable by any read-only-all bedel via canViewPractica

PRE-EXISTING, independent of the lector work. updateImageRotation (src/app/(protected)/practicas/actions.ts) admits anyone who passes canViewPractica. bedel passes it, so any of the 4 active bedel users can rotate any practica image in the system. bedel is documented read-only-all (CAPS: manageRoster, manageAttendance, viewAllPracticas - no write cap over case content), so this is a write reachable by a role that is not supposed to have one. NOT closed by the MARS-744 diff: the new isReadOnlyCaseViewer helper requires !manageRoster and bedel holds manageRoster, so the helper returns false for bedel by construction and gates only lector. Closing this needs a DIFFERENT predicate - the lector helper cannot be widened without also pulling in the roster and admin surfaces it deliberately excludes. Evidence either way is unavailable from data: successful rotations are not logged (only failures and rejects), and db-mars-cc found 0 appEvents rows matching rotat*, so whether any bedel has ever rotated an image is unknowable. 341 active practicaImages rows carry a non-zero rotationDegrees, so the feature is used by someone. The 4 active bedel users are Romina Seron (bedel+ayudante), Endodoncia FOUBA (bedel only - a SHARED catedra account, so its actions attribute to no individual), Elazar Pimentel (all roles) and Magali Ayelen (bedel only). Decision needed before any change: is rotation intended to be within bedel's job, or is read-only-all meant literally? If it is removed, at least two of those accounts may lose a workflow and nobody can tell in advance which. That is a product call, not a security emergency - low priority, but it should not be left as an undocumented accident. Worth pairing with: add success telemetry for rotation, so this question is answerable next time instead of being re-derived as unknowable.