Mobile practica-create failures are undiagnosable: client 'Failed to fetch' leaves no server-side row

A student lost a practica create on mobile with NO server-side row to diagnose from. EVIDENCE: appEvents 71b7d471-d905-4f41-a4a9-a495f682b1e9, 2026-08-24 09:29:14.924 UTC. level=warn, category=client, action=unhandled-error, route=/practicas/nueva, message='Failed to fetch'. detail: os=Android, browser=Chrome, isMobile=true, isSkewRetry=false, serverEventId=NULL. actorUserId=9dae1821-f8a5-42aa-b12f-6b6a5ae8a84e. CONFIRMED USER IMPACT: no practicas row exists for that user. Their only other event that morning is a toast/nudge-shown at 09:17. So the create was attempted and lost. NOT THE api-images OUTAGE - deliberately kept out of MARS-677's bucket. No targetHost, no causeCode, serverEventId NULL: the request never reached our server, so this is the CLIENT's network, not ours reaching api.pensanta.com. It is also 3.5h after the BR-812 window closed. BASE RATE, so nobody treats this as a new fire: 3 occurrences in 30 days (08-01, 08-09, 08-24), 1 user each. Low frequency. The reason it still earns a WI is that it is UNDIAGNOSABLE, not that it is frequent - a lost submission that leaves no server-side trace cannot be counted, correlated, or shown to be fixed. SCOPE (audit-mars-ca's spec, tag mt71rxrmrf7x): add a client-side create-failure event carrying route + action, a stable request/correlation ID, a sanitized cause class, and the user-visible retry outcome - WITHOUT claiming server receipt. The last clause is the load-bearing one: the whole point is that we do not know whether the server ever saw it, so the event must not imply it did. COUNTING TRAP TO AVOID: see reference_friction_telemetry_counting_traps - a static-key sessionOnce would collapse repeated attempts by the same student into one row, which is exactly the signal we need (the MARS-677 window showed one student retrying 4x in 15 min and only a per-attempt row made that visible).