fix: cargo install ignoring Cargo.lock

[fabriziosestito]

Description

By default, the Cargo.lock file that is included with the package will be ignored by cargo install.

Since the Dockerfile uses cargo auditable install, there were scenarios where the build regenerated Cargo.lock with updated dependencies.

As a result, the CI passed while the Docker build failed (see [GitHub Actions run](https://github.com/kubewarden/policy-server/actions/runs/12902609277/job/35976498867)).

This PR updates the Dockerfile to add --locked to the cargo auditable install instruction, fixing the issue.

[fabriziosestito]

Wouldn't it be better to run build --release instead of install?

[jvanz]

I think is fine to do that. We just need to copy the binary later, in the final image, from a different place.

[flavio]

I would be fine replacing the install with build --release as long as this doesn't make the Dockerfile more complicated (this is a multi-arch image, the build artifact would be located under two different paths, based on the architecture)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.58%. Comparing base (fbe1b09) to head (3330629).
Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1047   +/-   ##
=======================================
  Coverage   63.58%   63.58%           
=======================================
  Files          17       17           
  Lines        1071     1071           
=======================================
  Hits          681      681           
  Misses        390      390           

Flag	Coverage Δ
integration-tests	56.26% <ø> (ø)
unit-tests	37.29% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[flavio]

Good catch! I'm fine with the current PR, but I'm also open to use the build --release command as stated on my comment

[flavio]

I would be fine replacing the install with build --release as long as this doesn't make the Dockerfile more complicated (this is a multi-arch image, the build artifact would be located under two different paths, based on the architecture)

[viccuad]

Nice catch indeed!