Should Dependabot be updating lock (such as Gemfile.lock) files?

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Package ecosystem

Bundler

### Package manager version

_No response_

### Language version

_No response_

### Manifest location and content before the Dependabot update

The `/Gemfile.lock` file was updated for a new version of a dependency.

```
diff --git a/Gemfile.lock b/Gemfile.lock
index 56f03bb..a407842 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -195,7 +195,7 @@ GEM
rspec-mocks (~> 3.12)
rspec-support (~> 3.12)
rspec-support (3.12.1)
- rubocop (1.54.1)
+ rubocop (1.54.2)
json (~> 2.3)
language_server-protocol (>= 3.17.0)
parallel (~> 1.10)
```

### dependabot.yml content

```
version: 2
updates:
- package-ecosystem: "bundler"
directory: "/"
schedule:
interval: "weekly"
```

### Updated dependency

rubocop from 1.54.1 to 1.54.2

### What you expected to see, versus what you actually saw

It's not clear to me if Dependabot updates transitive dependencies.

What I saw when running `bundler outdated --strict` and `bundler update` for rubocop matches, but these commands also updated other dependencies. However, it only shows me that this particular case works. It does not demonstrate that all necessary rules for transitive dependencies would be applied or rules across the Gemfile would be applied.

At this point, I don't have any evidence that I can trust Dependabot's PRs to do all of the necessary updates. At most, I can use them as a flag to run `bundler outdated --strict` and `bundler update` and apply those changes. And at this point, I'd rather have an issues created and managed rather than a PR.

### Native package manager behavior

I ran `bundle outdated --strict` on the same branch. This showed 4 gems that could be updated: irb, public_suffix, rspec-mocks, and rubocop. Of these, only rubocop is in the Gemfile. The others are transitive dependencies that can be updated and still meet the requirements in the Gemfile.

The output for rubocop was exactly what Dependabot suggested. This only indicates that no transitive updates needed to be updated in a way that changed the ruled in the Gemfile.lock and says nothing about the correctness of the behavior should they need to be updated.

### Images of the diff or a link to the PR, issue, or logs

_No response_

### Smallest manifest that reproduces the issue

_No response_

Start with the /Gemfile.lock diff and the dependabot.yml Bundler configuration, then compare Dependabot's behavior with `bundle outdated --strict` and `bundle update` for the listed direct and transitive gems. Done means the transitive-dependency behavior is clarified or corrected and verified against a minimal reproduction.

Written by the indexing model from the issue text.