Fix five high-severity bugs from the full-session code review

- ProductSync: bsc_work.wc_product_id could go stale if a product was ever
  deleted out-of-band (wp-admin, a cleanup script). wc_get_product() then
  correctly detects "no product" and creates a new one, but the repoint was
  gated behind `if (!$existing_id)` — which was already true, so the stale
  ID never got corrected. Every future sync repeated this, one duplicate
  product per run. Fixed by making the repoint unconditional (cheap,
  idempotent UPDATE either way). Reproduced the exact scenario against dev
  (deleted a product out-of-band, ran sync-products twice) and confirmed:
  one repoint, zero duplicates, product count and per-work product count
  both correct across repeated runs.

- Commands.php (sync-hardcover-tags): wp_set_object_terms() with an empty
  array clears the taxonomy rather than leaving it alone — verified
  directly. Hardcover legitimately returns no moods/content-warnings for
  plenty of books, so a --force re-sync could silently wipe existing tags,
  including anything hand-tagged. Fixed by skipping the call per-category
  when that category's array is empty. Verified via a direct eval test:
  pre-existing genre tag survives a sync where genre comes back empty,
  mood still gets set normally.

- docker-compose.yml: two stray root-owned secrets/db_password and
  secrets/db_root_password directories were already sitting on disk —
  Docker auto-creating a bind-mount source as a directory from an earlier
  manual `docker compose` call that ran without ENVIRONMENT exported
  (reproducing the exact bug already fixed once this session). Removed
  the stray dirs and changed every `${ENVIRONMENT}` in a volume mount to
  `${ENVIRONMENT:?ENVIRONMENT must be set}` so Compose now hard-fails
  instead of silently defaulting to empty. Verified: unset ENVIRONMENT now
  fails config validation with a clear error; set, it still works.

- HARDCOVER_API_TOKEN moved to the same _FILE secrets pattern already used
  for DB_PASSWORD/DB_ROOT_PASSWORD (docker-compose.yml, deploy.sh,
  HardcoverAdapter.php) — it was a live, consumed secret still going
  through Compose's ${VAR} interpolation, exposed to the same
  mangling bug already fixed for the DB passwords, plus visible via
  `docker inspect`. deploy.sh now writes secrets/<env>/hardcover_api_token
  (optionally empty). Verified via deploy.sh dev + wp eval: empty file ->
  is_configured() false, a real token value -> true.

- backup.sh: mariadb-dump had no --single-transaction, so a dump against a
  live site would either table-lock for its duration or produce a
  non-atomic/inconsistent dump. Added; verified a real dump still runs
  clean and produces a valid, restorable-looking .sql.gz.

deploy/backup.sh

@@ -29,7 +29,13 @@ grep -Ev '^(DB_PASSWORD|DB_ROOT_PASSWORD)=' "$ENV_FILE" > "$COMPOSE_ENV_FILE"
 COMPOSE="docker compose -p bookstore-${ENVIRONMENT} -f docker-compose.yml -f docker-compose.${ENVIRONMENT}.yml --env-file ${COMPOSE_ENV_FILE}"
 
 echo "==> dumping database"
-$COMPOSE exec -T db sh -c "exec mariadb-dump -u\"\$MARIADB_USER\" -p\"\$(cat /run/secrets/db_password)\" \"\$MARIADB_DATABASE\"" \
+# --single-transaction: without it, a dump against a live site either
+# table-locks for its duration (blocking writes) or, if MARIADB_USER lacks
+# LOCK TABLES privilege, produces a non-atomic dump — rows written after the
+# dump starts but before it reaches their table can be captured
+# inconsistently with rows it already passed. InnoDB (this project's engine
+# throughout) supports a consistent snapshot via a single transaction instead.
+$COMPOSE exec -T db sh -c "exec mariadb-dump --single-transaction -u\"\$MARIADB_USER\" -p\"\$(cat /run/secrets/db_password)\" \"\$MARIADB_DATABASE\"" \
   | gzip > "$BACKUP_DIR/db-${TIMESTAMP}.sql.gz"
 
 echo "==> archiving uploads"

deploy/deploy.sh

@@ -60,12 +60,19 @@ DB_ROOT_PASSWORD_VALUE="$(env_get "$ENV_FILE" DB_ROOT_PASSWORD)"
 : "${DB_ROOT_PASSWORD_VALUE:?set DB_ROOT_PASSWORD in ${ENV_FILE}}"
 printf '%s' "$DB_PASSWORD_VALUE" > "$SECRETS_DIR/db_password"
 printf '%s' "$DB_ROOT_PASSWORD_VALUE" > "$SECRETS_DIR/db_root_password"
+# Optional, unlike the two above — an environment without a Hardcover token
+# just leaves HardcoverAdapter::is_configured() false. Written unconditionally
+# (even empty) so the bind mount in docker-compose.yml always has a real file
+# to point at, never a directory Docker auto-creates for a missing path (the
+# exact bug ENVIRONMENT-unset guards elsewhere in this file exist to prevent).
+HARDCOVER_API_TOKEN_VALUE="$(env_get "$ENV_FILE" HARDCOVER_API_TOKEN)"
+printf '%s' "$HARDCOVER_API_TOKEN_VALUE" > "$SECRETS_DIR/hardcover_api_token"
 # 644, not 600: the db/wordpress/cron containers read this as their own
 # (non-host-matching) container UID, e.g. www-data — chmod 600 made it
 # unreadable to them. The containing directory (700, above) is what
 # actually keeps other host users out; these just need to be world-readable
 # within that already-restricted directory.
-chmod 644 "$SECRETS_DIR/db_password" "$SECRETS_DIR/db_root_password"
+chmod 644 "$SECRETS_DIR/db_password" "$SECRETS_DIR/db_root_password" "$SECRETS_DIR/hardcover_api_token"
 
 echo "==> building and starting ${ENVIRONMENT}"
 $COMPOSE up -d --build