fix: SWA env file restore, build-arg quoting, Docker rollback cd_prefix, dead if-True

[thor-guardrail]

Summary

Four distinct bugs found during code review, grouped here because they're all correctness/safety fixes.

---

1. providers/azure/swa.py — .env.production.local deleted but never restored

Severity: Bug (data loss)

The SWA deployer backs up .env.production before overwriting it for the build, and restores it in the finally block. However, .env.production.local was also deleted (to prevent it from overriding the build env), but was never restored. This means that if a project had a .env.production.local file, a failed or successful SWA deploy would permanently destroy it.

Fix: Backup the file's contents before deleting, restore in finally.

Additionally: if .env.production didn't exist before the deploy, the finally block only restored it when env_production_backup is not None. When the file was freshly created, it would be left behind. Now cleans it up in that case too.

---

2. providers/azure/container.py + builders/docker.py — _build_args_str() doesn't quote values

Severity: Bug (silent failure)

--build-arg KEY=VALUE was constructed without quoting VALUE. Any build arg value containing spaces, $, backticks, or other shell metacharacters would be misinterpreted by the shell (both functions use shell=True). For example, CACHE_BUST=2024-01-01T12:00:00Z is fine, but a NODE_ENV=production build or anything with a space would silently corrupt the Docker build command.

Fix: shlex.quote() applied to each value.

---

3. cli.py — if True: dead code in _check_access()

Severity: Code quality (dead code)

_check_access() had:

if True:
    console.print(...)

This is always executed, making the guard meaningless. It was likely a placeholder during development. The behaviour (always printing an access-granted dim line) is actually reasonable as an audit trail, so the fix just removes the dead guard and adds an explanatory comment.

---

4. providers/docker/container.py — rollback() missing cd_prefix on second chained command

Severity: Bug (wrong directory)

In the no-target-revision rollback path:

f"{cd_prefix}docker compose -f {compose_file} down {service_name} && "
f"docker compose -f {compose_file} up -d {service_name}"  # ← missing cd_prefix

When project_dir is set, the cd_prefix moves to the right directory for the first command. But after &&, the shell is still in the original directory for the second command. The docker compose up runs from the wrong directory and will fail to find docker-compose.yml unless it happens to be in the SSH default path.

Fix: Add cd_prefix to the second command.

---

Files changed

• dds/providers/azure/swa.py
• dds/providers/azure/container.py
• dds/builders/docker.py
• dds/cli.py
• dds/providers/docker/container.py