Sync lockfile self-version to 0.104.0 and track it in .codegen.json

[mihaimitrea-db]

Summary

Fixes the check-lock CI job, which has been failing on every PR since the v0.104.0 release, and wires the lockfile self-version into .codegen.json so the release bot keeps it in sync going forward.

Net effective diff:

• lockfile.json: "version": "0.103.0" → "0.104.0" (project self-version stamp)
• databricks-sdk-java/lockfile.json: "version": "0.103.0" → "0.104.0", plus 91 "resolved" URLs normalized from the stale maven-proxy.dev.databricks.com proxy back to repo.maven.apache.org/maven2 (checksums and selected versions unchanged)
• .codegen.json: both lockfile.json entries added to the version map so the release bot bumps the self-version stamp alongside the pom.xml files at release time

Why

Commit c4823843 "[Release] Release v0.104.0" bumped the project version in all 5 pom.xml files from 0.103.0 → 0.104.0, but did not update lockfile.json or databricks-sdk-java/lockfile.json. Both still recorded "version": "0.103.0" for the project's own GAV.

mvn maven-lockfile:validate was failing every PR with:

Your lockfile from file is for:     com.databricks:databricks-sdk-parent:0.103.0
Your generated lockfile is for:     com.databricks:databricks-sdk-parent:0.104.0

The release only bumped the self-version — no dependencies were added, removed, or changed — so no transitive SHAs needed to change.

How the regenerated lockfile was produced

Running make lock locally in a sandbox without JFrog OIDC credentials isn't possible, so the regeneration was done inside CI on this branch (where setup-build-environment provides OIDC-authenticated JFrog access). Commits 5d376ce1 and 54e67137 on this branch are the bootstrap + bot-generated regeneration; commit bbc7fd7d reverts the bootstrap. The net effect is identical to what make lock && make fix-lockfile would have produced locally.

Prevention: .codegen.json update

Per Hector's suggestion, added both lockfile.json files to the version map in .codegen.json with an anchor pattern of:

"artifactId": "<id>",\n  "groupId": "com.databricks",\n  "version": "$VERSION"

This ensures the release bot updates the self-version stamp in both lockfiles on future releases, preventing this mismatch from recurring.

User impact

None. lockfile.json is consumed only by maven-lockfile:validate in CI; it is not published to Maven Central. The SDK artifacts downstream consumers pull are unaffected.

How is this tested

The PR's own check-lock job is the test — it should transition from red to green. Verified green on the bot-regenerated commit 54e67137.

Commits on this branch (suggest squash-merge)

30ed03f4 Track lockfile version in .codegen.json
bbc7fd7d Remove temporary regenerate-lock CI job
54e67137 Regenerate lockfile via CI        ← by github-actions[bot]
5d376ce1 [TEMP] Add regenerate-lock CI job
08636130 Sync lockfile self-version to 0.104.0

---

NO_CHANGELOG=true

This pull request and its description were written by Isaac.

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-java

Inputs:

• PR number: 770
• Commit SHA: 30ed03f4cb3e71636e646949b25f70d1d2e69454

Checks will be approved automatically on success.