test: profile-map drift guard + reverse-switch coverage for profile deactivation (#822)

[VijitSingh97]

Two test-tier hardenings for the merged #804 profile-deactivation fix. Tests only — no behavior changes; the drift guard passes green against the current map, so no unmapped service exists today.

Drift guard (tests/stack/test_compose.sh)

remove_deactivated_profile_containers hardcodes the service↔profile map, so a future profile-gated service added to docker-compose.yml would silently escape removal. The guard (same pattern as #565's depends_on count guard):

• renders the compose file with --profile '*' so every profile-gated service appears regardless of its profile name, and extracts service=profile pairs via jq;
• parses the same pairs out of the function body in the pithead script;
• fails unless the two sorted sets are identical — a new profile-gated service, a renamed profile, or a stale map entry all trip it, with both sides printed. An empty compose-side set also fails, so a broken render can't pass vacuously.

Negative-tested: dropping the monerod line from the map makes the guard fail with both sets shown.

Reverse-switch coverage (tests/stack/run.sh)

New case (4) in the #795 block: commits a tari-remote .env, then drives a tari remote→local switch through apply against the stubs and asserts:

• the reconcile removes only the still-off profiles (compose rm -sf monerod wallet-rpc tari-wallet — no tari in the list, so the reactivated service's container is never touched);
• the recreate up runs after that reconcile;
• local_tari is back in the committed COMPOSE_PROFILES, which is what makes that up bring the tari container up again.

Verification

• tests/stack/run.sh: 1696 passed, 0 failed
• tests/stack/test_compose.sh: all green
• make lint: rc 0

Closes #822

🤖 Generated with Claude Code