Per the C-3 design, mesh state lives on central. Pilots learn aliases
via the D-1 override push and hold them in `pilotAliasOverlay`. The
local `mesh_stacks` table on pilots has been dead since C-3 shipped.
This is a greenfield cleanup (Directive 20):
- `migrateMeshTables()` runs `DROP TABLE IF EXISTS mesh_stacks` when
`SENCHO_MODE === 'pilot'` and skips the CREATE. Central-mode
behavior is unchanged.
- The four mesh CRUD methods (`listMeshStacks`, `isMeshStackEnabled`,
`insertMeshStack`, `deleteMeshStack`) short-circuit on the same
check. Reads early-return empty/false; writes early-return;
`insertMeshStack` also warns so an accidental pilot-side write is
loud.
- New `isPilotMode()` helper mirrors the existing one in
`bootstrap/startup.ts`. Layering rules forbid the shared import; a
third call-site would justify extraction to `helpers/`.
Operator-visible behavior is unchanged on either side. On central, the
table and its rows are untouched. On pilots, the table is removed (it
held no rows in steady state) and any caller of the CRUD methods
continues to see empty list / false / no-op without touching SQLite.
Test plan
- `npx tsc --noEmit`: clean.
- New `database-service-pilot-mesh-stacks.test.ts`: 5/5 green (table
absence + four short-circuit assertions).
- `mesh-service.test.ts`, `mesh-diagnostic-local.test.ts`, and
`mesh-service-proactive-bootstrap-fanout.test.ts`: 58/58 green.
- Full backend suite: 2280/2281; the single failure is a pre-existing
Windows EBUSY flake in `filesystem-backup.test.ts` that reproduces
on a clean tree.
- Code reviewed; findings applied.
Anso