ci(deploy): publish images via Gitea Registry and verify on CD

CI workflows now own image publishing: backend-ci and frontend-ci push
service images to the Gitea Registry tagged with commit8. CD workflows
(nas-compose-deploy, nas-compose-service-deploy, offline-package, the
new nas-k3s-deploy) pull and verify those tags instead of rebuilding,
so deployments fail fast when CI hasn't produced the matching image.
The shared deploy/scripts/gitea-registry-images.sh helper drives both
the ensure (CI) and verify (CD) paths, and package.sh can now hydrate
its local images from the registry via SOURCE_IMAGE_REGISTRY.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

task_plan.md

@@ -269,6 +269,13 @@ Phase 37
 - [x] Update findings/progress and summarize deployment commands plus required edits
 - **Status:** complete
 
+### Phase 39: Gitea Registry CI/CD Boundary
+- [x] Keep image publishing owned by frontend/backend CI only
+- [x] Make CD/offline workflows verify commit8 images instead of building fallback images
+- [x] Keep deploy-config CI scoped to deployment config validation only
+- [x] Run workflow YAML and shell syntax checks
+- **Status:** complete
+
 ## Key Questions
 1. How should the desktop client defer and locally optimize monitor-task execution without violating one-task-per-platform serialism?
 2. What is the smallest durable local cache that allows same-day resume while safely dropping stale next-day monitor tasks?
@@ -320,6 +327,8 @@ Phase 37
 | Split daily monitoring plan loading into selection and aggregation steps | Primary-client election and platform authorization aggregation have different explainability and testability concerns; two smaller queries are easier to inspect and later move to sqlc |
 | Treat platform-account health as execution state, not authorization state | `health != live` should not suppress daily task planning, dashboard authorization, or detail history; only desktop-client online state gates immediate collection |
 | Start k3s with a self-contained stack that mirrors the existing compose deployment | The repo already has working Docker images and compose topology; k3s should first preserve service names and runtime assumptions before introducing managed cloud replacements |
+| Publish deployable images only from frontend/backend CI | Deployment config has no runtime image ownership; `deploy-config-ci` stays a validation workflow while frontend/backend CI publish Gitea Registry images tagged by commit8 |
+| Use commit hash first 8 chars as the canonical deploy image tag | CD/offline packaging can compare the pushed commit to Registry tags and fail fast when CI has not produced the matching image |
 
 ## Errors Encountered
 | Error | Attempt | Resolution |