Co-located SLM Manager: nginx duplicate upstream autobot_backend blocks Phase 4c (frontend site not disabled before nginx -t) #9933

Summary

On a co-located SLM Manager, nginx -t fails during Phase 4c with:

nginx: [emerg] duplicate upstream "autobot_backend" in /etc/nginx/sites-enabled/autobot-slm:6

This blocks the SLM-wizard provision (the "SLM Nginx Co-location Update" phase) and the host is dropped, so AI Stack / NPU / TTS / LLM / Browser phases run as empty plays.

Root cause — phase ordering

Two enabled site files both declare upstream autobot_backend:

• sites-enabled/autobot-frontend:6 (enabled by the frontend role, Phase 4b)
• sites-enabled/autobot-slm:6 (co-location config, fix: backend/frontend roles deploy conflicting nginx configs on single-host #2829)

nginx.conf does include sites-enabled/*, so both load → duplicate.

The frontend role already has a "Disable standalone nginx when co-located (#2829)" task gated on slm_colocated_frontend, but that flag is only set later, in the slm_manager role / Phase 4c (provision-fleet-roles.yml L427-448). When the frontend role runs in Phase 4b the flag is still false, so it enables autobot-frontend and never removes it. Phase 4c re-renders autobot-slm and runs nginx -t without first removing the now-conflicting autobot-frontend symlink → emerg.

Fix

In playbooks/provision-fleet-roles.yml Phase 4c, before SLM | Test nginx config after co-location update (L492), remove /etc/nginx/sites-enabled/autobot-frontend when _is_slm_frontend_colocated is true, and include that removal in the nginx test/reload trigger conditions.

Acceptance

• Co-located SLM Manager passes nginx -t on first provision
• Only one upstream autobot_backend is loaded (autobot-slm)
• Idempotent; non-co-located frontend hosts keep their standalone site