Commit composer.lock so CI and releases install a fixed dependency set

composer.lock was gitignored, so `composer install` resolved the graph afresh
on every job. CI could quietly start testing different dependency versions
than it did the day before, and two builds of the same tag could ship
different vendor trees — the run that produces the zip is the same run that
picks the versions.

Track the lock, and make the two places that consume it use it:

- the Composer cache keys hash composer.lock rather than composer.json, since
  the lock is now what actually fingerprints the dependency set;
- bin/build-zip.sh stages the lock alongside composer.json, so the --no-dev
  production install resolves to the locked versions. It already deleted both
  from the staging directory before zipping, so the shipped plugin is
  unchanged.

The current lock installs cleanly on 8.1: nothing in it requires a PHP newer
than the >=8.1 composer.json declares.

Closes #187

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2

bin/build-zip.sh

@@ -23,6 +23,10 @@ INCLUDE=(
 	"$SLUG.php"
 	"uninstall.php"
 	"composer.json"
+	# Staged so the production install below resolves to the locked versions
+	# rather than whatever is newest that day. Both are deleted again before
+	# the zip is written.
+	"composer.lock"
 	"src"
 	"templates"
 	"assets"