[runyaga]

Implements the dart_monty part of milestones M1 and M2 of issue 9 of the dart_monty_extras repository (error handling), and pins dart_monty_core v0.110.0-dev.4. Upstream pydantic-monty 1.1.0 is the specification. Every change is additive.

Changes

• Pin dart_monty_core v0.110.0-dev.4 (e962659) in the root and example pubspecs, pages.yaml, the docs and the demo pages. The pubspec comment states that core is released as git tags only.
• The facade re-exports Frame, MontyRuntimeError, MontySyntaxError, MontyTypingError, MontyCrashedError, MontyExceptionValue and FrameTooLargeException, so a consumer reads traceback frames and the error subtype from the dart_monty import alone.
• BridgeRunError gains displayMessage, cause, causeStack and throwCause(). extractBridgeResult rethrows through throwCause().
• HostFunction.parity registers a host function whose arguments and result follow 1.1.0. Its handler may return any Dart object: null becomes None, and an object with no Monty form raises Python TypeError with upstream's "Cannot convert ..." text. A call that its parameters cannot bind raises Python TypeError with the CPython message, in upstream's order: keywords in call order (unexpected keyword, multiple values), then too many positional, then missing. The original HostFunction constructor is unchanged.
• docs/reference/upstream-divergences.md lists the behaviours that differ from 1.1.0: D-1 (the legacy binder keeps RuntimeError), D-2 (an opaque return is impossible through the legacy handler type) and D-3 (dart_monty checks argument types against the schema). It inherits core's C-1 to C-12. The pinning tests name their row id.
• DCM baselines: unnecessarily-public 71 to 75 (owner-approved: +3 for the BridgeRunError getters, +1 for HostFunction.parity). The lib ratchet drops 9 to 0 and the test ratchet 844 to 834.

Test-count floors are unchanged.

Tests

Each behaviour change was committed as a failing test before its fix.

Unit	Red on the base	Green after
Error parity	test/integration/error_parity_test.dart: 32 cases recorded from pydantic-monty 1.1.0 (tool/record_error_parity.py), comparing exception type, message, every display format, traceback frames, data and external calls. Fails to compile on the base: the error types are not exported	VM, dart2js, dart2wasm
Facade errors and BridgeRunError	the error types and getters do not exist	VM, dart2js, dart2wasm
HostFunction.parity	the constructor does not exist; then two(1, 2, a=4) binds silently; then two(1, 2, 3, a=4) reports the positional count instead of multiple values	test/integration/host_function_parity_test.dart, test/src/host/schema_test.dart, all backends

Local results at this head:

Cell	integration	acceptance	portable
vm	709	12	69
chrome-dart2js	547	12	69
chrome-dart2wasm	547	12	69

dart analyze --fatal-infos is clean, bash tool/dcm_host_gate.sh is green, and check_core_ref, check_page_versions and check_demo_pages pass. The VM cell's native workspace tests need the build_worker: true opt-in from docs/contributor/testing.md, as CI adds it.

Pre-PR review

Each unit had a design review and a code review from a second reviewer. Findings fixed:

• the parity binder let a keyword overwrite a positional argument;
• the parity binder checked the positional count before keywords, which reverses upstream's precedence (confirmed against pydantic-monty 1.1.0);
• missing tests for a parity handler that throws a Dart exception and for the legacy binder on DispatchMode.future;
• unnecessarily public parity handler fields.

Declined:

• throwCause() adds one stack frame to the StateError for a BridgeRunError with no cause. Type and message are unchanged.
• The parity handler's FutureOr result is awaited unconditionally. Dispatch is asynchronous on both paths, so Python cannot observe the difference.

Follow-ups

• dart_monty_extras repins to the dev tag cut from this merge and adds its lowered-tool parity test.
• The remaining M1 and M2 rules (diagnostics envelope, callback history) are later milestones of issue 9 of the dart_monty_extras repository.