libpod: report locks that DeallocateAllLocks failed to remove

[nishantbkl3345-ship-it]

DeallocateAllLocks() declares lastErr and returns it, but never assigns to it. When os.Remove() fails on a lock file, the function logs a line and carries on, so it always returns nil and the caller is told every lock was freed.

The log line is not helpful either: "Deallocating lock %s" is formatted with the path only. It never mentions that anything failed and drops err, so the reason — EACCES, EROFS, EBUSY, ENOTEMPTY — is lost.

The user-visible effect is on podman system renumber, which calls FreeAllLocks() before it reassigns lock IDs (libpod/runtime_renumber.go). With the file lock backend, a renumber that could not clear the old lock directory can still report success and go on to allocate new locks. The file backend is the default on FreeBSD, and it is selected on Linux by lock_type = "file" in containers.conf.

The unused lastErr dates back to commit 827ac0859f96 (lock: new lock type "file"), which added the backend.

Keep the newest failure in lastErr and return it, wrapped with the path so the caller can identify which lock is stuck, and log any failure it supersedes. This follows the same lastErr pattern used elsewhere in libpod, for example in ExecHTTPStartAndAttach() in libpod/container_exec.go. Removal still continues over the remaining locks, and a lock file that is already gone is still skipped, so successful deallocation is unchanged.

The test makes one entry of the lock directory impossible to remove and checks that DeallocateAllLocks() returns an error naming it, and that the other locks are freed regardless. A non-empty directory is used to provoke the failure because os.Remove() rejects it with ENOTEMPTY rather than a permission error, which keeps the test working in both root and rootless test environments.

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

• I have read and understood our [contributing guidelines](https://github.com/podman-container-tools/podman/blob/main/CONTRIBUTING.md) and will not have more than two open PRs as a new contributor.
• PR description, commit message, and GitHub comments are human-written, per [LLM Policy](https://github.com/podman-container-tools/community/blob/main/LLM_POLICY.md)
• Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match the sign-off email address. See https://github.com/podman-container-tools/podman/blob/main/CONTRIBUTING.md#sign-your-prs for more information.
• Referenced issues using Fixes: #00000 in commit message (if applicable)
• [Tests](https://github.com/podman-container-tools/podman/tree/main/test#readme) have been added/updated (or no tests are needed)
• [Documentation](https://github.com/podman-container-tools/podman/blob/main/docs/README.md) has been updated (or no documentation changes are needed)
• All commits pass make validatepr (format/lint checks)
• [Release note](https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md) entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

podman system renumber now reports an error when the file lock backend cannot remove a lock file, instead of reporting success.