`--lockfile_mode=off` does not actually prevent reading the lockfile

### Description of the bug:

We had an issue where we turned off the lockfile but hit an issue where downloading from the BCR still led to a checksum failure based off of a sha in the lockfile.

```
Checksum was X but wanted Y
```

Documentation indicates that `--lockfile_mode=off` should "neither read from or write to the lockfile".

> --lockfile_mode= default: “update” : Specifies how and whether or not to use the lockfile. Valid values are update to use the lockfile and update it if there are changes, refresh to additionally refresh mutable information (yanked versions and previously missing modules) from remote registries from time to time, error to use the lockfile but throw an error if it’s not up-to-date, or off to neither read from or write to the lockfile.

AI identified this culprit line, but I'm not knowledgeable enough to say if this is or isn't the culprit. It does certainly seem suspicious, though.

https://github.com/bazelbuild/bazel/blob/aac8677f8e69e30fb105026ff524e04965640499/src/main/java/com/google/devtools/build/lib/bazel/bzlmod/RegistryFactoryImpl.java#L65

### Which category does this issue belong to?

_No response_

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Run a small build with `--lockfile_mode=update`
1. Open the lockfile, go to `registryFileHashes`, modify one of the hashes to something else.
1. Run the same small build with `--lockfile_mode=off`
1. Notice an error about a bad checksum

### Which operating system are you running Bazel on?

Ubuntu 22.04.5 LTS jammy

### What is the output of `bazel info release`?

release 9.2.0

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text
We're using an internal repository, so the output would be useless.
```

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

Unsure if this is a regression. We only noticed the behavior when we turned lockfile_mode off and had a bad checksum. We've turned it on and off in the past but it's hard to know if there was a bad checksum or not when those happened.

### Have you found anything relevant by searching the web?

Not for this specific issue. There are other `--lockfile_mode`-related issues but they are not related to this specific behavior, as far as I can tell.

### Any other information, logs, or outputs that you want to share?

None. This seems fairly straightforward as a violation of publicly documented behavior and the culprit the AI found does seem related.

Start at src/main/java/com/google/devtools/build/lib/bazel/bzlmod/RegistryFactoryImpl.java around line 65 and reproduce the issue by modifying registryFileHashes, then running the build with --lockfile_mode=off. Trace whether the lockfile hash is read in off mode; done when the documented behavior is restored and the regression is covered by a test.

Written by the indexing model from the issue text.