Profile photo escalating nag -> hard block on 10th prompt; show photo in practica for teacher identification

GOAL (Elazar, 2026-07-30): students upload a profile photo so the photo can be shown on the practica so a teacher can tell who the student is in the chair. ESCALATION LADDER as specified: prompts 1-3 friendly ask, 4-6 stronger, 7-9 final notice, 10th = BLOCKED until a photo is uploaded. OPEN DESIGN QUESTIONS (must be answered before implementing, do not guess): 1. What event increments the counter? Login / session start / visit to /mi-cursada / calendar day? A login-keyed counter and a page-view-keyed counter give wildly different real-world timelines (a student who opens the app 10x in one afternoon would be blocked the same day). 2. Scope of the block. It must NOT block: logout, /solicitar-acceso, the upload page itself, or support ticket filing - otherwise a student who cannot upload has no way out and no way to ask for help. Proposal: block every protected route except the upload surface + soporte, redirect there with the reason stated in Spanish. 3. Does the block apply to teachers/admins or students only? Spec says student. 4. Is a photo ever removable once uploaded (re-enters the ladder?), and does an admin override exist? KNOWN RISK, flag before build: MARS-567 documented a real decode-failure class on Android via the Google Fotos / Drive cloud picker (stub file, arrayBuffer throws). A HARD BLOCK gated on an upload path with a known device-specific failure mode can lock a real student out of the app entirely. Whatever the ladder, the block needs an escape hatch (soporte reachable + admin clear) or MARS-567's failure becomes a lockout instead of a retry loop. TELEMETRY: the 9 prompts and the block screen are user-facing feedback -> log under appEvents category 'toast' with detail.mechanism per evolutiva-commons No Silent Failures + Friction Telemetry. Do NOT log success. AUTH/VISIBILITY: profile avatars are already peer-visible under the image-proxy auth contract (profile-any-auth vs clinical-scoped split), so surfacing the photo to the practica's teacher needs no new gate - confirm against src/app/api/image-proxy before assuming. CLASS: touches auth/permission gating (a route-level block) -> Class-A push, pre-impl audit design ping + pre-push diff review.