Commit the lockfile

[danielballan]

This PR ensures that developers get a validated, working environment out of the box. It also solves the problem, "Library X put out a new release last night and now all PRs opened today are failing due to this regression unrelated to the context of the PR."

• Drop pixi.lock from .gitignore. Note why uv.lock is still in the `.gitignore.
• Create and commit pixi.lock.
• Create a workflow that runs on a weekly schedule that will open a PR to update the lockfile.
• Run tests against the locked pixi environment.
• Add a job to the nightly build [or maybe a separate nightly build, with a separate failure state] that creates a fresh lockfile (pixi update) and runs the tests. This will provide prompt warning for, "Library X put out a release that broke us." This is important because the pixi.lock file only protects developers who have cloned the repo. It doesn't affects users who are installing tiled from the package on conda-forge.

[danielballan]

About a year ago, I found that solving tiled dependencies spiked pixi's usage of system resources, sometimes even crashing my Ubuntu Thinkpad. For that reason, I went with uv for our CI jobs. This no longer seems to be an issue, so I think we can move to using pixi in CI.