RUST-136 Add missing gradle.lockfile for root project

[saberduck]

• Root project has no resolvable configurations so Gradle never generates a lockfile for it
• SonarQube rule S8569 (LockfileForJavaCheck) checks for lockfile presence on any build.gradle.kts that is not a submodule, regardless of build file content
• Adding an empty lockfile satisfies the rule and unblocks the quality gate

[hashicorp-vault-sonar-prod]

RUST-136

[sonar-review-alpha]

Summary

This PR adds a minimal gradle.lockfile to the root project to satisfy the SonarQube rule S8569, which requires lockfiles on all top-level build.gradle.kts files.

The root project itself has no resolvable dependency configurations—it only contains plugin declarations and shared build logic—so Gradle never generates a lockfile for it. However, the SonarQube check doesn't distinguish between projects with dependencies and those without, so an empty lockfile with the standard boilerplate comment is added. This unblocks the quality gate without changing any actual build behavior.

What reviewers should know

Context for reviewers:

• The root build.gradle.kts enables dependencyLocking { lockAllConfigurations() } for all projects, which should ensure every project has a lockfile.
• Other subprojects (buildSrc, sonar-rust-plugin, e2e) already have their own lockfiles with actual locked dependencies.
• The new root lockfile contains only empty= because there are no dependency configurations to lock at that level—just plugins and shared build configuration.
• This is a minimal, non-invasive change that does not affect build behavior; it purely satisfies a static analysis requirement.

Nothing to verify:

• The lockfile format is standard and follows the pattern of existing lockfiles in the project.
• No actual build or dependency changes are involved.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

Clean, minimal fix. The empty= format (no configuration names) is the correct Gradle output for a project with zero resolvable configurations — distinct from empty=configName which other subprojects use to list configurations that exist but have no locked dependencies. The .gitignore does not exclude gradle.lockfile, so the file will be tracked correctly. No CI steps regenerate or verify lockfiles in a way that would conflict. If the root project later gains resolvable configurations, ./gradlew dependencies --write-locks will update the file automatically.

🗣️ Give feedback

[romainbrenguier]

For me that's a false positive, since we already have settings-gradle.lockfile.

[saberduck]

For me that's a false positive, since we already have settings-gradle.lockfile.

yes, I reported to the cloud security squad

[sonarqube-next]

Quality Gate passed for 'sonar-rust'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube