Summary

• tree-sitter-dart represents an arrow-bodied function (int f() => x + 1;) as function_body containing the expression DIRECTLY — no return_statement node at all. dataflowDart's returnNode: 'return_statement' never matched, so arrow-bodied functions never recorded a returns entry — a distinct semantic gap from Dart: function_signature/method_signature never contains its own body — breaks per-function complexity/dataflow analysis #2182's sibling-body fix (an implicit return via => isn't modeled as a return at all).
• Adds a new implicitReturnBodyNode/blockBodyNode config pair to DataflowRulesConfig: when a configured node's only named child is not the block type, that child is recorded as an implicit return the same way handleReturn already does for a real return_statement (it only ever reads namedChildren[0], so it works unmodified regardless of the wrapper node's actual type).
• Enabled only for Dart (implicitReturnBodyNode: 'function_body') — no other language sets this field, so this is purely additive with zero behavior change elsewhere.
• Rust's native engine has no Dart dataflow rules at all yet (tracked separately as follow-up: Rust engine needs DartDataflowRules to match TS's now-fixed dataflowDart #2359), so this is legitimately TS/WASM-only — no dual-engine parity gap for this specific fix.
• While verifying, found that calls nested inside a return/other expression are never tracked at all for Dart (argFlows stays empty even for an ordinary block-bodied function) — a separate, pre-existing gap, unrelated to this fix. Filed as follow-up: Dart dataflow — calls nested inside a return/other expression are never tracked #2497.

Test plan

• New tests in tests/parsers/dataflow-dart.test.ts: implicit return from a top-level arrow-bodied function, from an arrow-bodied class method, and a check that a block-bodied function isn't double-counted
• Full test suite: 328 files / 5263 tests passed
• npm run lint clean
• diff-impact — contained (1 function changed, 1 transitive caller)

Closes #2356