Container Registry Backing Store Full 507

A registry can still answer reads while being unable to accept a single blob byte. Treat local ENOSPC, S3 quota exhaustion, and blocking storage backends as an explicit write-health failure, not an opaque 500 or a healthy `/v2/` response.

Runbook: A Readable Registry Can Still Be Write-Dead

1. Do not use `GET /v2/` or read-only storage stat as proof that pushes can succeed.
2. Translate full-store errors into a stable operator-facing status: local `ENOSPC`, `EDQUOT`, S3 quota exceeded, and object-store capacity errors should not collapse into generic 500.
3. Add a write-aware readiness probe that initiates a tiny upload against localhost and expects the normal upload-start response within a strict timeout.
4. If the backend can block writes instead of returning errors, add server-side deadlines or readiness timeouts so upload connections do not remain established indefinitely.
5. When write readiness fails, return 503 from the main listener or remove the instance from the load balancer for push traffic.
6. Keep probe upload debris bounded with upload purging and a probe repository that cannot hide real tenant data.
7. Document the safe cleanup boundary: upload sessions, temp files, logs, and garbage-collection steps are different from manifests and referenced blobs.

I would frame this as a registry write-health contract, not only a v2.x status-code gap.

Acceptance checks I would want:
- Full local stores map ENOSPC/EDQUOT to a stable 507 Insufficient Storage response instead of UNKNOWN/500.
- Object-store or S3 quota errors map to the same operator-facing class.
- Read-only health remains separate from write health; GET /v2/ can stay green while push readiness fails.
- A write-aware readiness mode initiates a tiny upload and fails within a bounded timeout if the backing store cannot accept writes.
- Blocking backends get request/write deadlines so upload sockets do not stay established forever.
- Probe upload debris is bounded by upload purging or a dedicated probe repository.
- Docs say which upload/session files are safe to purge and which blob/manifest paths are not.

Do Not Delete First

• Referenced blobs or manifests before running registry-aware garbage collection.
• Upload session state before understanding whether clients are still attached.
• Object-store buckets or prefixes without proving retention, tag, and manifest reachability.
• Readiness probes that only prove reads while write paths are failing.