Make dart_hooks config keys a single source of truth + guard shipped examples

[reidbaker]

Summary

Follow-up to #150 / #151. That fix corrected the shipped dart_hooks.yaml files, but two gaps let the wrong-key bug ship undetected in the first place, and this hardens against both:

1. Test helpers hardcoded the keys independently of the code. test/test_utils.dart wrote 'DartAnalyzeHook' / 'DartFormatHook' as string literals, so the test's notion of the key could drift from each hook's configKey with nothing reconciling them.
2. No test ever loaded the committed example files. Tests wrote their own temp configs (which happened to use the correct keys), so the broken shipped files never reddened anything.

Changes

• Single source of truth: add a static const String configKeyName to DartFormatHook and DartAnalyzeHook; the configKey getter now delegates to it. BaseHook.run() still gates on the polymorphic instance getter, so runtime behavior is unchanged.
• Derive test keys: mockAnalyzeConfig / mockFormatConfig in test_utils.dart now build their YAML from configKeyName instead of literals — the test's keys can no longer drift from the code.
• Guard the shipped files: new test/example_config_test.dart loads each committed dart_hooks.yaml (package root, tool/, repo root, tool/dart_skills_lint/) and asserts both configKeyName keys are present and true, mirroring BaseHook.run()'s enablement gate. A guard test fails loudly if no shipped files are found, so a wrong working directory can't pass the suite vacuously.

Verification

• dart analyze --fatal-infos — no issues
• dart format --output=none --set-exit-if-changed on the touched files — clean
• dart test — 32 pass (was 27)
• Negative check: temporarily reverting a shipped file to the old agent_dart_format.dart: true keys made example_config_test.dart fail on exactly that file while the other three passed; restored afterward.

[gemini-code-assist]

Code Review

This pull request introduces static configKeyName constants to DartAnalyzeHook and DartFormatHook to prevent configuration keys from drifting, and updates test utilities to use these constants. It also adds a new test suite example_config_test.dart to verify that the shipped dart_hooks.yaml files correctly enable both hooks. A review comment suggests adjusting how packageRoot is resolved in the test suite to ensure correct path resolution when tests are executed from the monorepo root instead of the package root.

[gemini-code-assist]

When running tests from the monorepo root (e.g., dart test tool/dart_hooks), Directory.current points to the monorepo root rather than the package root. This causes the relative paths in candidatePaths to resolve incorrectly, resulting in 3 out of the 4 configuration files being silently skipped during verification.

Adjusting packageRoot to point to the actual package directory when run from the monorepo root ensures all 4 configuration files are always verified.

    var packageRoot = Directory.current.path;
    final toolDartHooks = path.join(packageRoot, 'tool', 'dart_hooks');
    if (Directory(toolDartHooks).existsSync()) {
      packageRoot = toolDartHooks;
    }
    final candidatePaths = <String>[
      path.join(packageRoot, 'dart_hooks.yaml'),
      path.join(packageRoot, '..', 'dart_hooks.yaml'),
      path.join(packageRoot, '..', '..', 'dart_hooks.yaml'),
      path.join(packageRoot, '..', 'dart_skills_lint', 'dart_hooks.yaml'),
    ];

[reidbaker]

Pr in draft because I am not sure the new test is worth adding.