fix(docs): document hardened FlowMonk Docker workaround

docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md

@@ -178,6 +178,24 @@ At the time of writing:
 - FlowMonk host-side pilot migration is validated
 - FlowMonk backend/web Docker builds are validated locally with a real token plus `--add-host localhost:host-gateway`, but the default advertised tarball URL shape is still not clean enough to call this solved generically
 
+Verified local FlowMonk Docker recipe on this Mac:
+
+```bash
+TOKEN='<local-gitea-package-token>'
+
+docker build \
+  --add-host localhost:host-gateway \
+  --build-arg GITEA_NPM_HOST=host.docker.internal \
+  --secret id=gitea_npm_token,env=TOKEN \
+  -f backend/Dockerfile /Users/sd9235/code/mygh/learning_ai_flowmonk
+
+docker build \
+  --add-host localhost:host-gateway \
+  --build-arg GITEA_NPM_HOST=host.docker.internal \
+  --secret id=gitea_npm_token,env=TOKEN \
+  -f web/Dockerfile /Users/sd9235/code/mygh/learning_ai_flowmonk
+```
+
 That blocker must be resolved before we can claim full local E2E completion.
 
 ---

docs/devops/SINGLE_VM_DEPLOYMENT.md

@@ -719,7 +719,7 @@ The remaining work is concentrated more in the **build and package-distribution
 - local Homebrew Gitea package metadata and tarball URLs are not yet reliable across both host installs and Docker builds
 - FlowMonk backend/web Docker builds are now green locally only when using a real Gitea package token plus `--add-host localhost:host-gateway`; that workaround is not yet the final default/VM-ready shape
 - local Gitea Actions has not yet been fully validated for the package publish + consumer install path
-- the pilot registry migration is only validated for FlowMonk backend/web host-side usage, not end-to-end across Docker and all surfaces
+- the pilot registry migration is validated for FlowMonk backend/web host-side usage plus local Docker builds with the documented workaround, but not yet end-to-end across CI and all surfaces
 
 ### Azure VM readiness gaps