Wait for dashwise and tududi in CI, document both

The deploy job only waited on the deployments that existed when it was
written, so a broken rollout of either new app would have been reported
as a successful deploy.

Also records the two new secrets in the bootstrap table, and the two
traps found while adding these: dashwise publishes :latest for amd64
only, and a server-side dry run of a brand new namespace reports every
resource inside it as missing until the namespace exists.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitea/workflows/deploy.yaml

@@ -93,13 +93,13 @@ jobs:
           kubectl rollout status deploy/pihole -n pihole --timeout=10m
           kubectl rollout status deploy/unbound -n pihole --timeout=10m
           kubectl rollout status deploy/unifiedstreaming -n unified-streaming --timeout=10m
-
+  
       - name: Deployment summary
         if: always()
         run: |
           echo "## Deployment Summary" >> $GITHUB_STEP_SUMMARY
           echo '```' >> $GITHUB_STEP_SUMMARY
-          for ns in bitwarden default home-assistant nginx pihole unified-streaming; do
+          for ns in bitwarden default dashwise home-assistant nginx pihole tududi unified-streaming; do
             kubectl get deployments -n $ns >> $GITHUB_STEP_SUMMARY || true
           done
           echo '```' >> $GITHUB_STEP_SUMMARY

README.md

@@ -22,6 +22,8 @@ Each app under `apps/` is a self-contained kustomization
 | pihole | pihole | admin on :8000 via klipper-lb, DNS on :53 |
 | unbound | pihole | pi-hole's upstream recursive resolver (ClusterIP only) |
 | unified-streaming | unified-streaming | unified.wittyoneoff.com |
+| dashwise | dashwise | home.wittyoneoff.com, origin-home.wittyoneoff.com |
+| tududi | tududi | tududi.wittyoneoff.com, origin-tududi.wittyoneoff.com |
 
 Not in this repo: socktop (own repo + pipeline), rancher/monitoring/logging
 (rancher-managed), traefik (k3s packaged component).
@@ -35,7 +37,7 @@ kubectl apply -k apps/home-assistant   # one app
 
 ### One-time secret bootstrap (per cluster)
 
-Three apps read secrets that are NOT in git. Each app dir has a
+Five apps read secrets that are NOT in git. Each app dir has a
 `secret.example.yaml`; copy to `secret.yaml` (gitignored), fill in, apply.
 
 | Secret | Namespace | Used for |
@@ -43,6 +45,8 @@ Three apps read secrets that are NOT in git. Each app dir has a
 | `pihole-admin` | pihole | pi-hole admin `WEBPASSWORD` |
 | `usp-license` | unified-streaming | `USP_LICENSE_KEY` |
 | `searxng-1723974683-config` | default | searxng `settings.yml` |
+| `dashwise` | dashwise | PocketBase superuser (also the admin UI login) |
+| `tududi` | tududi | login + `TUDUDI_SESSION_SECRET` cookie signing key |
 
 ~~**One-time migration (pihole + unified-streaming)**~~ — DONE 2026-07-26:
 secrets `pihole-admin` and `usp-license` created in-cluster and both
@@ -56,7 +60,7 @@ deployments switched to `secretKeyRef` via `kubectl replace` (a plain
 
 - **PRs** → `kubectl apply -k . --dry-run=server` (validation only)
 - **push to main** → `kubectl apply -k .` + `kubectl rollout status` on all
-  seven deployments
+  nine deployments
 
 Repo Actions secret required: `KUBECONFIG` — base64-encoded kubeconfig for the
 `gitea-deployer` ServiceAccount (same identity socktop-webterm deploys with;
@@ -100,6 +104,11 @@ to secrets and no delete verbs.
 - vaultwarden and home-assistant carry helm-chart-era label/name shapes but
   their release records are gone; they are plain manifests now.
 - pihole runs `privileged: true` with `PIHOLE_UID=0`.
+- dashwise `:latest` and `:stable` are built for amd64 only and will not run
+  on these nodes; it is pinned to a tag that publishes an arm64 manifest.
+- dashwise and tududi both create namespaces, so the very first
+  `--dry-run=server` for a new app reports "namespace not found" for
+  everything inside it. Create the namespace first, then validate.
 
 ## History