release: registry pointer 실패 조건을 release 문서에 고정한다

ops/backend-release-dispatch.md

@@ -105,6 +105,7 @@ The frontend workflow that receives this event is:
 
 - `summary`
 - `metadata.previous_deploy_image` - backend Jenkins resolves the image behind the registry `latest-prod`/`prod` pointer before the new deploy
+- When the registry pointer is missing or no canonical digest match exists, backend deployment must stop or require explicit bootstrap approval.
 - `metadata.pull_request_number`
 - `metadata.pull_request_labels`
 

ops/release-record-shared-contract.md

@@ -2,6 +2,8 @@
 
 This is the shared production release-record contract between `study-platform-mvp` backend and `study-platform-client` frontend.
 
+Direct pushes to `main` without a PR and its `release:major|minor|patch` label are not valid production release inputs.
+
 It fixes two schemas:
 
 1. the backend-to-frontend release payload schema, and
@@ -132,6 +134,7 @@ The frontend script also accepts the inner `client_payload` object directly when
 
 - `summary`
 - `metadata.previous_deploy_image` - backend Jenkins resolves the image behind the registry `latest-prod`/`prod` pointer before the new deploy
+- The release record is still the audit trail; the registry pointer only helps backend Jenkins recover the previous immutable backend image before dispatch.
 - `metadata.pull_request_number`
 - `metadata.pull_request_labels`
 

ops/version-management.md

@@ -4,6 +4,8 @@ This document is the frontend repository source of truth for ZERO-ONE production
 
 This document follows the shared FE/BE contract in `ops/release-record-shared-contract.md`.
 
+- Do not direct-push commits to `main` or bypass the PR path. Production deploy/release recording depends on the PR and its `release:major|minor|patch` label.
+
 ## Responsibility
 
 - `study-platform-client` owns the final production release record because it is the user-facing application and the running product depends on a compatible frontend/backend/database combination.