apply leaves the deactivated-profile tari container running after a local→remote switch

[VijitSingh97]

Reproduced live on the bench appliance. Switching tari.mode local→remote and running
pithead apply -y:

• the preview correctly warned "the local tari container will be STOPPED and removed";
• the render correctly dropped local_tari from COMPOSE_PROFILES;
• p2pool was correctly recreated with --merge-mine tari://gouda.lan:18142;
• but the tari container was left RUNNING — apply's own later output said "the tari
  container is recreated (brief restart)" for a TARI_MEM change, i.e. the memory-diff path
  recreated the very container the mode switch had just removed. It then ran a full
  minotari_node against a remote-mode config, OFFLINE and flailing, and would have re-synced
  the chain into a dir the operator had just reclaimed.

podman rm -f tari followed by pithead up converges correctly and the container stays gone
— so the steady state is right; the transition is the bug. Likely the recreate list is built
from the .env diff BEFORE profile deactivation is considered, so tari appears in the "changed,
recreate" set even though its profile is off. The monerod local→remote path deserves the same
check (#103's e2e proved fresh-remote, not switch-to-remote).

Coverage: a stack-level test that drives a local→remote tari switch through apply against the
compose stubs and asserts the tari container is absent afterwards — the KVM phases never
exercise a post-provision mode switch.

[VijitSingh97]

Not appliance-specific — the apply transition bug affects DIY identically. Fix lands on develop directly.

[VijitSingh97]

Root cause confirmed, one level below the hypothesis: there is no pithead-built recreate list — the recreate set is compose's own resolved-config diff. The actual hole was that nothing ever removed the deactivated-profile container: apply delegated cleanup to compose up -d --remove-orphans (the code comment even claimed that drops monerod on a local→remote switch), but a profile-disabled service is still defined, so its container is not an orphan — and while it survives, compose treats the service as enabled again. The TARI_MEM_LIMIT diff that rides every tari switch (auto-calc → the remote-mode placeholder) then made the same compose up recreate the node the switch had just turned off.

monerod was equally affected (local_node, same --remove-orphans delegation — the #103 e2e only proved fresh-remote, as suspected), plus the two payout-confirmation wallets when a view key is cleared, and the upgrade path (it re-renders .env too).

Fix in #806: apply/upgrade now stop and remove every container whose profile the committed .env switched off, before the recreate up — keyed off the committed .env so the #125 marker retry converges too. Stack-tier tests drive both local→remote switches through the real apply against the compose stubs and assert the container is absent afterwards (and that the removal precedes the up).