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/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.