Route the profile-photo nag upload through the MARS-567 honest-copy validator before uploadProfileImage

MARS-580 precondition (a) of 2, both required before BLOCKING_RUNG_ENFORCED can go back to true in src/lib/profile-photo-nag.ts. The nag's upload form (src/components/profile-photo-nag.tsx) posts straight to the uploadProfileImage server action. It does NOT pass through src/lib/image-client.ts, where MARS-567 put the honest copy for the Android cloud-picker stub case (Google Fotos/Drive lazy content:// URI -> file.slice/arrayBuffer THROWS -> errorKey image-upload:unreadable-file). Server-side, 'await file.arrayBuffer()' throws into uploadProfileImage's outer catch and returns error.message raw. Consequence when the block is on: an affected Android student sees an unhelpful raw string on a screen with nothing else on it, and cannot get back into the app. That is the lockout MARS-580 flagged as a known risk before build. FIX: run the same client-side validation/decode path the /practicas/nueva upload uses before submitting, so the unreadable-file case produces MARS-567's copy. Class-S, client-only. Verify the copy renders inside the nag panel, not just on /perfil.