feat(devops): local GitLab secret bootstrap + integration registration scripts

Adds PowerShell helpers to seed the local Stella Ops stack with a working
GitLab + integrations configuration:
- bootstrap-local-gitlab-secrets.ps1 provisions GitLab's JWT signing secret
  and admin PAT into Vault/Authority.
- register-local-integrations.ps1 POSTs the canonical integration records
  (GitLab, Jenkins, Harbor, Gitea, Nexus, etc.) against the Integrations
  service for first-run local environments.

Docs: INSTALL_GUIDE.md + integrations/LOCAL_SERVICES.md document the new
helpers. devops/compose README and router-gateway-local.json get the
corresponding route wiring. Two new sprint files track the follow-on work
(SPRINT_20260413_002, SPRINT_20260413_003).

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

devops/compose/README.md

@@ -281,6 +281,41 @@ docker compose \
 docker compose -f docker-compose.integrations.yml ps gitea
 ```
 
+Register the default local-ready integration catalog once the stack is up:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
+  -Tenant demo-prod
+```
+
+The helper creates and verifies the 13 turnkey local providers on a fresh
+machine. GitLab server/CI and the GitLab registry remain opt-in because they
+require Vault-backed PAT material. The scripted local path is:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File scripts/bootstrap-local-gitlab-secrets.ps1 `
+  -VerifyRegistry
+
+powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
+  -Tenant demo-prod `
+  -IncludeGitLab
+
+powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
+  -Tenant demo-prod `
+  -IncludeGitLab `
+  -IncludeGitLabRegistry
+```
+
+Or run the GitLab-backed registration in one step:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File scripts/register-local-integrations.ps1 `
+  -Tenant demo-prod `
+  -IncludeGitLab `
+  -IncludeGitLabRegistry `
+  -BootstrapGitLabSecrets
+```
+
 **Hosts file entries** (add to `C:\Windows\System32\drivers\etc\hosts`):
 ```
 127.1.2.1  gitea.stella-ops.local
@@ -322,7 +357,7 @@ vault kv put secret/nexus admin-password="your-password"
 
 Gitea is now bootstrapped by the compose service itself: a fresh `stellaops-gitea-data` volume creates the default local admin user and the repository root before the container reports healthy. Personal access tokens remain a manual step because Gitea only reveals the token value when it is created.
 
-When you enable the optional GitLab registry surface (`GITLAB_ENABLE_REGISTRY=true`), register it through the `GitLabContainerRegistry` provider with `authref://vault/gitlab#registry-basic`. The local Docker registry connector now follows the registry's Bearer challenge and exchanges that `username:personal-access-token` secret against `jwt/auth` before retrying catalog and tag probes.
+For GitLab, `scripts/bootstrap-local-gitlab-secrets.ps1` is the preferred local bootstrap path. It reuses a valid `secret/gitlab` secret when possible and otherwise rotates the local `stella-local-integration` PAT, then writes `authref://vault/gitlab#access-token` plus `authref://vault/gitlab#registry-basic` into the dev Vault. When you enable the optional GitLab registry surface (`GITLAB_ENABLE_REGISTRY=true`), register it through the `GitLabContainerRegistry` provider with `authref://vault/gitlab#registry-basic`. The local Docker registry connector now follows the registry's Bearer challenge and exchanges that `username:personal-access-token` secret against `jwt/auth` before retrying catalog and tag probes.
 
 `docker-compose.testing.yml` is a separate infrastructure-test lane. It starts `postgres-test`, `valkey-test`, mocks, and an isolated Gitea profile on different ports; it does not start Consul or GitLab. Use `docker-compose.integrations.yml` only when you need real third-party providers for connector validation.