Workspace startup completion is invisible in CLI and web UI

[rfay]

Problem

When a workspace is created via coder create or through the web UI, the command/UI returns as soon as the container is running — but the startup script (starting Docker daemon, installing DDEV config, etc.) continues running in the background. There is no clear signal to the user that setup is actually finished.

Concretely:

• coder create returns while the workspace is still mid-setup
• coder ssh <workspace> may succeed but the workspace isn't ready for use
• The web UI shows "Running" before DDEV and Docker are actually usable
• In CI (coder ssh --wait=yes) we're waiting for the agent to connect, not for the startup script to complete — so subsequent steps can fail on a still-booting workspace

Relevant Coder primitives

The Coder provider offers two mechanisms to address this:

1. startup_script_behavior = "blocking" on the coder_agent resource — blocks coder ssh and marks the workspace "Starting" in the UI until the inline startup script exits. (Coder docs: startup_script_behavior)

2. start_blocks_login = true on a coder_script resource — blocks login until that named script completes. Allows separating the startup logic into a distinct, named script visible in the UI. (Coder docs: coder_script)

Either approach would make the workspace not reachable via SSH until setup is complete, giving a clear and reliable done signal in both CLI and web UI.

Proposed investigation

• Evaluate whether setting startup_script_behavior = "blocking" on the existing inline script is sufficient, or whether the startup logic should be moved into a dedicated coder_script resource with start_blocks_login = true
• Consider the UX tradeoff: blocking means coder create takes longer to return, but the workspace is actually ready when it does
• Check whether this also fixes the CI race in the integration test workflow (currently works around it with --wait=yes but that only waits for agent connection, not startup completion)

Relates to #71.