fix: repair production lock through direct mount

deploy/README.md

@@ -254,7 +254,7 @@ The deploy and migration workflows share the `staging-mutation` Actions concurre
 
 Use Gitea Actions → **Create Production Recovery Point** from the exact current `main` release SHA before every production schema migration. The manual workflow requires `main`, `staging`, public staging health, and the successful release gate to identify the same SHA. It uses the pinned production SSH identity, shares the `production-mutation` lock, and runs `deploy/run-production-recovery.sh` with shell tracing disabled.
 
-The host script writes an AES-256-CBC/PBKDF2 encrypted custom-format PostgreSQL dump under `/opt/jyotisha-production/backups`, restores it into a uniquely named disposable database, validates non-sensitive row/table counts, removes only that disposable database, and writes a mode-`0600` verification manifest. Before acquiring the shared host lock it validates that `.state` and `backups` are real directories, then reuses the existing passwordless Docker boundary to run the already-loaded PostgreSQL image with no network, a read-only root filesystem, all capabilities dropped except `CHOWN`, and only those two directories bind-mounted. That helper restores an existing regular `mutation.lock` before changing its mode-`0700` parent directory, then restores the two directory mount points to the current `deploy` UID/GID. The child-first order lets the least-privilege helper retain traversal without adding `DAC_OVERRIDE`; it never recursively changes backup files or removes or replaces a lock inode. The workflow retrieves only the encrypted dump and verification metadata, verifies the SHA-256 digest, and uploads them as a 30-day Gitea Actions artifact with compression disabled. The artifact-backed `recovery_reference`, `recovery_created_at`, and `restore_verified=true` output are the inputs for **Migrate Production Database**. Do not use the attestation if backup, restore, retrieval, digest validation, ownership normalization, or artifact upload fails.
+The host script writes an AES-256-CBC/PBKDF2 encrypted custom-format PostgreSQL dump under `/opt/jyotisha-production/backups`, restores it into a uniquely named disposable database, validates non-sensitive row/table counts, removes only that disposable database, and writes a mode-`0600` verification manifest. Before acquiring the shared host lock it validates that `.state` and `backups` are real directories, then reuses the existing passwordless Docker boundary to run the already-loaded PostgreSQL image with no network, a read-only root filesystem, all capabilities dropped except `CHOWN`, and only the two directories plus the verified existing lock inode bind-mounted. That helper exposes the regular `mutation.lock` directly at `/mutation.lock`, restores that inode before changing its mode-`0700` parent directory, then restores the two directory mount points to the current `deploy` UID/GID. The direct file mount avoids depending on traversal through a parent left half-repaired by an earlier failed run, without adding `DAC_OVERRIDE`; it never recursively changes backup files or removes or replaces a lock inode. The workflow retrieves only the encrypted dump and verification metadata, verifies the SHA-256 digest, and uploads them as a 30-day Gitea Actions artifact with compression disabled. The artifact-backed `recovery_reference`, `recovery_created_at`, and `restore_verified=true` output are the inputs for **Migrate Production Database**. Do not use the attestation if backup, restore, retrieval, digest validation, ownership normalization, or artifact upload fails.
 
 Never restore over `jyotisha`, delete the PostgreSQL volume, print `.env.production.database`, expose `PRODUCTION_BACKUP_ENCRYPTION_KEY`, or substitute a staging recovery artifact. The encrypted local archive is preserved for repair; the Actions artifact supplies the required off-host copy.
 

deploy/run-production-recovery.sh

@@ -35,13 +35,19 @@ done
 install -d -m 700 "$state_directory" "$backup_directory"
 deployment_uid="$(id -u)"
 deployment_gid="$(id -g)"
+ownership_mounts=(
+  --volume "$state_directory:$state_directory"
+  --volume "$backup_directory:$backup_directory"
+)
 ownership_targets=()
 if [ -e "$lock_file" ]; then
   [ -f "$lock_file" ] && [ ! -L "$lock_file" ] || {
     echo "production mutation lock is unsafe" >&2
     exit 1
   }
-  ownership_targets+=("$lock_file")
+  ownership_lock_target="/mutation.lock"
+  ownership_mounts+=(--mount "type=bind,src=$lock_file,dst=$ownership_lock_target")
+  ownership_targets+=("$ownership_lock_target")
 fi
 ownership_targets+=("$state_directory" "$backup_directory")
 
@@ -62,8 +68,7 @@ ownership_image="$(sudo -n docker inspect --format '{{.Image}}' "$postgres_conta
 }
 sudo -n docker run --rm --pull never --network none --read-only --user 0:0 \
   --cap-drop ALL --cap-add CHOWN --security-opt no-new-privileges \
-  --volume "$state_directory:$state_directory" \
-  --volume "$backup_directory:$backup_directory" \
+  "${ownership_mounts[@]}" \
   --entrypoint chown "$ownership_image" \
   "$deployment_uid:$deployment_gid" "${ownership_targets[@]}"
 chmod 700 "$state_directory" "$backup_directory"