Completes local-dev-master-slave-setup: dual-instance frontend tooling, module-capability gating, and master/slave protocol self-healing fixes

Frontend (Unit 2 completion): dual dev-server tooling (pnpm dev:slave,
pnpm dev:all), per-instance browser tab titles, and a backend
capability check (SystemController + useSystemCapabilities +
ModuleGuard) so a Master-only page is hidden on a slave instance
instead of assuming every backend has every module.

Master/slave protocol fixes surfaced by actually running master and
slave side by side locally:
- Deactivating a CMS instance (Inactive) now releases the slave's
  master gate instead of leaving it stuck on its last pushed status.
- The periodic integrity check now also re-pushes status to every
  reachable slave (previously URL-verification only) and runs once
  immediately on startup.
- Added the originally-specified (but never implemented) slave-pull
  path: a slave now periodically polls its own status from the master
  (GET /api/v1/SlaveStatus) and fails open to Available if the master
  is unreachable for too long, complementing the existing push.
- The slave's own Settings page can no longer "successfully" change
  local availability while the master controls it; it's now locked
  with an explanatory banner and the backend rejects the write with
  409 instead of silently no-op'ing it.
- CMS instance status badges now match the dashboard's color/icon
  styling instead of a plain grey badge.

Also corrected the master-cms-module design docs to match this
as-built behavior, and flagged (without a full rewrite) a larger,
pre-existing divergence between its inception-stage application
design and what construction actually built.

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

aidlc-docs/features/tech-debt-backlog/audit.md

@@ -11,3 +11,15 @@
 **Context**: Feature aangemaakt tijdens master-cms-module sessie; geen actieve executie gestart, puur registratie voor later
 
 ---
+
+## TD-004 Added — Master-Controlled Availability Copy Review
+
+**Timestamp**: 2026-07-04T00:00:00Z
+
+**User Input**: "De tekst mag nog wel wat anders worden, maar ik weet nu even niet wat dus ik kan dat nu ook zelf niet veranderen. Kan je hier een tech debt item voor maken zodat ik dit later op kan pakken?"
+
+**AI Response**: "TD-004 toegevoegd aan backlog.md: de teksten voor de master-controlled availability-lock op SettingsPage (banner-titel, banner-body, en de 409-conflict-toast — drie i18n-sleutels in nl/en translation.json) zijn functioneel correct maar de exacte formulering moet nog herzien worden. Puur copy, geen logica-wijziging verwacht; genoteerd dat de bijbehorende SettingsPage.test.tsx-assertie op tekst matcht en dus mee moet worden aangepast bij het oppakken."
+
+**Context**: Item ontstond direct na de master-controlled-availability fix in local-dev-master-slave-setup (zelfde sessie, 2026-07-04); user wilde de tekst niet blokkerend laten zijn voor de rest van het werk.
+
+---

aidlc-docs/features/tech-debt-backlog/inception/requirements/backlog.md

@@ -43,6 +43,20 @@ Items discovered incidentally while working on other features. Not yet prioritiz
 
 ---
 
+## TD-004: Review copy for the master-controlled availability lock on `SettingsPage`
+
+**Found during**: `local-dev-master-slave-setup` — Build & Test follow-up fix (2026-07-04), user flagged the wording right after it was added but didn't have a replacement in mind yet.
+
+**Location**:
+- `frontend/src/pages/SettingsPage.tsx` (locked-state banner + disabled controls)
+- `frontend/src/i18n/locales/nl/translation.json` and `en/translation.json`, keys `settings.availability.masterControlledTitle`, `settings.availability.masterControlled`, `settings.availability.masterControlledSaveError`
+
+**Issue**: When a slave's availability is controlled by its Master CMS, the Settings page now shows a banner ("Beheerd door Master-CMS" / "Deze instantie is door de Master-CMS uitgeschakeld...") and disables the mode buttons, reason field, and save button, plus a specific toast on a 409 conflict ("Kan niet worden gewijzigd: de Master-CMS beheert deze status."). The behavior (locking + explaining why) is correct and intentional; only the exact phrasing needs a revisit — user wants different wording but hadn't decided on it at the time.
+
+**Done looks like**: Update the three translation keys above (NL and EN) to the reviewed copy. No code/logic changes expected — this is copy-only. Re-run `pnpm test` for `SettingsPage.test.tsx` afterward (its assertions match on text via regex, e.g. `/master cms controls this status/i`, so wording changes will need matching test updates too).
+
+---
+
 ## Notes
 
 - None of these block functionality — `npm run build` and all test suites pass regardless.