Decide whether a below-minimum custom/system Bun should hard-fail instead of warning

Start by reading validate_bun and tests/units/utils/test_utils.py::test_validate_bun_path_incompatible_version, then compare the documented behavior with the node validation path. First resolve which listed policy applies; done means the selected behavior is implemented, the test reflects it, and the validate_bun docstring agrees.

Split out of review feedback on #7019, which raised Bun.MIN_VERSION to 1.4.0.

The situation

validate_bun warns — but proceeds — when a non-default Bun is below MIN_VERSION:

if bun_version < version.parse(constants.Bun.MIN_VERSION):
    logger.warning(f"Reflex requires bun version {constants.Bun.MIN_VERSION} or higher ...")

That warning-only behavior is deliberate and pinned by tests/units/utils/test_utils.py::test_validate_bun_path_incompatible_version, whose body says so outright:

# This will just warn the user, not raise an error
js_runtimes.validate_bun()

Two things make it worth revisiting now:

1. The docstring disagrees with the code. validate_bun's Raises: section already claims SystemExit: If custom specified bun does not exist or does not meet requirements. It raises for a missing version, but only warns for a too-old one.
2. The consequence got sharper at the 1.4 boundary. Below-minimum used to mean "old, probably fine". It now means the Bun cannot parse lockfileVersion: 2 at all, so once any 1.4 build has updated reflex.lock/bun.lock, that Bun's install fails outright under --frozen-lockfile.
3. The node path already hard-fails. validate_frontend_dependencies raises SystemExit(1) when node is below Node.MIN_VERSION, so bun is the inconsistent one.

Why it wasn't changed in #7019

Only the REFLEX_USE_SYSTEM_BUN=1 / custom bun_path opt-in reaches this warning. The default path is already correct and was verified: with a system Bun 1.3.11 on PATH and no opt-in, install_bun declines to reuse it and installs the pinned 1.4.0 instead.

For the opt-in, the user has explicitly told Reflex to use their Bun, so honoring that with a warning is a defensible reading — and flipping it to a hard exit changes behavior an existing test deliberately asserts. That is a policy call rather than part of a dependency refresh, so #7019 only strengthened the warning text to name the lockfile consequence.

Options

• Hard-fail below MIN_VERSION, matching the docstring and the node path. Update test_validate_bun_path_incompatible_version to assert SystemExit.
• Fail only below the lockfile-compatibility floor (currently 1.4.0), keeping a soft warning for the merely-old range — needs a second constant to express "oldest Bun that can read the lockfile we write".
• Keep warning, and instead make the failure legible when it lands, e.g. detect error: Unknown lockfile version from the install and explain it.

What needs doing

• Pick one of the above
• Implement, and reconcile test_validate_bun_path_incompatible_version with the decision
• Make validate_bun's docstring and behavior agree either way