feat: flip --keep_going default to false

[tinder-maxwellelliott]

What

Flip the default for --keep_going from true to false across all commands that expose it:

• generate-hashes (and warmup, which inherits the option via ScopeType.INHERIT)
• fingerprint
• serve

fallbackValue stays "true", so a bare -k / --keep_going still enables it. The old behavior remains available by explicitly passing --keep_going.

Why

With --keep_going enabled, bazel query tolerates failures in the build graph and bazel-diff treats a partial query (exit code 3) as success. When a repository rule fails to resolve — e.g. a transient network error fetching a remote dependency — the package that references it silently disappears from the query results, and bazel-diff emits a hash set that is missing those targets with no error. That makes hashes non-deterministic across runs (a target present when a fetch succeeds vanishes when it flakes). This is the failure mode captured in the #398 reproducer.

Defaulting to false makes the common case fail loudly on configuration/resolution issues, keeping hashes deterministic.

Changes

• Source: defaultValue = "false", field initializers → false, and updated help text in GenerateHashesCommand, FingerprintCommand, ServeCommand.
• README: updated both help blocks (generate-hashes, serve) to Defaults to false with the new rationale.
• Tests: reworked the generate-hashes silently produces incomplete/non-deterministic hashes on repo-rule resolution failure (--keep_going=true default) #398 reproducer e2e test so the default path asserts fail-loud (exit 1), and the silent-drop behavior is demonstrated behind an explicit --keep_going. Fixed a now-stale "default behavior" comment in the Using --cquery can't skip targets #301 cquery test.

⚠️ Behavior change

This changes a user-facing default. Runs that previously relied on the implicit --keep_going will now fail on partial queries instead of silently producing truncated hashes; those callers must pass --keep_going explicitly to keep the old behavior. Worth a release-note callout.

Testing

• bazel build //cli:bazel-diff — clean.
• generate-hashes silently produces incomplete/non-deterministic hashes on repo-rule resolution failure (--keep_going=true default) #398 reproducer, Using --cquery can't skip targets #301 cquery-failing-target test, and the fingerprint unit tests pass.
• Full E2ETest: the 4 external-repo/cquery tests fail locally due to a pre-existing sandbox environment issue (nested coursier repo rule can't locate a JDK → bazel exit 37, rejected under both old and new allowed-exit-code sets); confirmed identical failure on master. Not caused by this change.

🤖 Generated with Claude Code