appEvents feedback-category canonicalization + native-validation quality refinements (folds into VENUS-183 standardization pass)

DO NOT BUILD YET — Elazar-gated timing (post-Jul-10 fold vs now, pm-mars put it to Elazar). Three refinements for the appEvents-standardization pass (VENUS-183, MARS-411 mirror): (1) ONE canonical category for ALL user-facing feedback with mechanism as a sub-field (toast|native-validation|inline-hint) — today native-validation lands as category='uxFriction'/action='nativeValidation:<type>' while toasts land cat='toast'/action toast-shown|error-shown: 3 category-ish tags for the same concept (user-shown feedback), so a DB/LLM query filtering one tag misses the others. Collapse to one filterable feedback tag + mechanism subfield. (2) Native-validation currently logs el.validationMessage = the BROWSER's default locale-dependent string (observed ENGLISH 'Please select a value that is no more than 2026') — for a Spanish app, log the constraint CODE (rangeOverflow, already captured) + an app-authored Spanish string, NOT the raw browser message. (3) field currently = el.name||el.id, which falls back to React's auto-generated DOM id ('_R_j1inpfiv5tpdb_-y') when the field sets no explicit name — useless for triage; capture the semantic field name/label instead (prefer explicit name/label, smarter fallback). Ref shipped native-validation: VENUS-184/16b2cbc; NativeValidationReporter capture-phase 'invalid' listener.