Implement debug console warning surface

The kDebugMode constant from flutter/foundation is a compile-time constant in release builds, so the Dart compiler and tree-shaker will eliminate the entire block — but only if the guard is structured as `if (kDebugMode) { ... }` and not stored in a variable first. Do not use `assert(() { ... }())` as this can behave differently from kDebugMode in profile mode.

For the runAllChecksAndWarn() convenience method, collect all three violation lists into a combined list and call dispatchWarnings once to allow a single summary header line before the individual violations. Consider prefixing each line with a severity indicator (🔴 for critical accessibility violations, 🟡 for high) — but only if the team's debug console convention already uses emoji; otherwise use plain ASCII prefixes like [CRITICAL] and [HIGH] to maintain consistency with the rest of the codebase.

Unit tests using flutter_test. Scenarios: (1) dispatchWarnings([]) in debug mode → zero debugPrint calls, (2) dispatchWarnings([violation]) in debug mode → one debugPrint call containing route path, violation type, and remediation hint, (3) dispatchWarnings([v1, v2, v3]) → three separate debugPrint calls, each containing correct violation data, (4) simulate release mode (override kDebugMode or extract the guard into a testable helper) → zero output for non-empty list, (5) runAllChecksAndWarn() with no violations → zero output, (6) runAllChecksAndWarn() with known mock violations from all three verifiers → correct combined output. Use a captured output buffer or a spy on debugPrint to assert output content without relying on stdout parsing.