POC: compare Traefik with the dynamic development proxy

[vitormattos]

This draft PR compares the nginx-proxy implementation from #129 with an equivalent Traefik-based POC.

The comparison keeps the same developer contract and UX:

• a plain docker compose up
• multiple concurrent checkouts
• automatic shared proxy lifecycle
• *.localhost HTTPS routes
• the LibreCode dashboard at https://localhost
• friendly handling for unknown hostnames
• runtime diagnostics
• project hostname certificate validation
• equivalent Bats integration coverage

What Traefik removes

Traefik replaces the nginx-proxy/docker-gen routing layer, so this POC removes the custom docker-gen.cfg, Procfile, nginx-proxy vhost overrides, and the 54-line proxy asset installer.

What is still required

The developer UX is not provided by the native Traefik dashboard. To preserve the experience from #129 this POC still needs:

• a dedicated HTTP server for the LibreCode dashboard
• a custom dashboard consuming Traefik route metadata
• Traefik router/service/network labels on the routed Compose services
• the shared proxy coordinator and lifecycle logic
• multi-checkout lease handling
• runtime diagnostics
• project network attachment/detachment

The Traefik API used by the dashboard is kept on a non-published internal entrypoint and proxied through the dashboard HTTP server.

Comparison with #129

With both implementations aligned and tested:

• feat: prototype dynamic development proxy dashboard #129 against main: 34 changed files, 1,577 additions / 391 deletions
• this Traefik implementation against main: 30 changed files, 1,604 additions / 432 deletions
• production files only: nginx-proxy has 849 additions, Traefik has 869 additions

The numbers are not a complexity score, but they show that replacing the routing component does not materially reduce the implementation needed to preserve the complete developer experience. Traefik simplifies routing/discovery itself, while some of that reduction moves into Compose labels and the separate dashboard HTTP layer.

One useful result from this POC was a better network architecture: instead of connecting application containers from all checkouts to one shared proxy network, the shared proxy connects to each active Compose project network. That keeps the project containers isolated from each other. The same improvement was applied back to #129.

Proxy unit tests, Docker integration tests, ShellCheck, and Compose validation pass for the POC.

This PR remains a comparison POC and is not intended to be merged as-is.