Add DNS caching troubleshooting docs and warnings

[michaelnchin]

Context

Follow-up to #145, which was closed as not planned because the root cause of the E2E test failure was traced to tests running from a cloud desktop on a corporate network, where DNS/proxy infrastructure delayed access.

In case users also have a restrictive network setup that would result in the same error, we should provide proper troubleshooting docs and warnings for resolution.

Action Items

• Add a section to TROUBLESHOOT.md explaining:

  • After jd up reports IN_SERVICE, the app URL is live (confirmed by LE cert issuance)
  • If you get NS_ERROR_UNKNOWN_HOST or similar DNS errors, the cause is likely your network's DNS/proxy infrastructure, not the deployment itself.
  • Link back to DNS Propagation Not Awaited in Deployment Waiter #145 for the full discussion.

• In jd open, if the initial connectivity check fails with a DNS resolution error, print a warning along the lines of:

  DNS may not have reached your network yet — the deployment is live. See TROUBLESHOOT.md for details.

[JGuinegagne]

Proposal: Host-side DNS remediation via config file

When E2E tests run from a cloud desktop (e.g., Amazon Linux with nscd + DNSOnHostCache), the host's DNS cache can serve stale/negative records after a fresh deploy or instance swap. The E2E test container uses --net=host, so the browser resolves DNS through the host's network stack — but the caching daemons live in the host's PID namespace and can't be flushed from inside the container.

Idea

Add a config file (e.g., .e2e-network.yaml) at the workspace root that lists shell commands to flush the DNS cache on the host:

# Commands to run on the host when DNS errors are expected
# (e.g., after fresh deploy or instance type change)
dns_remediation:
  - sudo nscd -i hosts
  - sudo systemctl restart dns-on-host-cache

The justfile's test-e2e recipe would read this file and run the commands on the host as a pre-flight step before launching tests. This is especially relevant for "deploy from scratch" mode where Route53 records are brand new.

Limitations

• Only helps at test start, not mid-run (e.g., if a mutating test triggers a DNS change).
• Host-specific: different environments need different commands.
• Requires sudo access for the test runner.

Alternatives considered

• Container-to-host signaling: The test plugin writes a trigger file; a host-side watcher flushes DNS. Works mid-test but adds significant complexity.
• Longer retry window: Increase retry count and backoff interval in _navigate_with_retry to outlast the DNS TTL. Zero infrastructure but wastes time on every run.