Clarify Codespaces Breeze startup context and improve Docker guidance

[linxi507]

This PR improves GitHub Codespaces onboarding for Breeze and makes the related Docker guidance less misleading.

It updates the beginner quick start and the dedicated Codespaces guide to clarify that:

• GitHub Codespaces already runs inside a containerized development environment
• breeze start-airflow should be run from the initial Codespaces terminal / outer shell with Docker access
• running it from inside an already-entered breeze shell or nested container shell can lead to misleading Docker-related errors

It also improves the Breeze error guidance shown when Docker checks fail in a container/devcontainer/Codespaces-like environment. Instead of only showing the generic "Docker is not running" message, Breeze now adds a more targeted explanation about the execution context.

Tests:

• added unit tests for the containerized-environment guidance path
• preserved coverage for the generic non-containerized path

Closes: #62405

---

Was generative AI tooling used to co-author this PR?

• Yes — Chat GPT-5

Generated-by: Chat GPT-5 following the guidelines at https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

[potiuk]

BTW. There should be rather easy way to "start-airflow" from the container - if you run in entrypoin_ci.sh - everythint that happens when START_AIRFLOW is set to a non-empty value is what happen when you do "start-airflow" - so maybe a good idea might be to write bash function (in_container_start_airflow)- extract it in entrypoint_ci.sh and run both during entrypoint_ci.sh of breeze start-airflow and when you rin in_container_start_airflow (or similar) in the devcontainer?

That might be a good way to give "start-airflow" functionality to devcontainer users.

[linxi507]

Thanks for the suggestion — that makes sense, especially for improving the developer experience inside devcontainers.

For this PR, I focused on clarifying the execution context and improving the guidance for the existing workflow, since the current error message can be misleading in Codespaces.

I agree that supporting a "start-airflow" flow directly inside the container (via something like in_container_start_airflow) could be a valuable enhancement. I’d be happy to explore that in a follow-up PR to keep this one focused and easier to review.

Let me know if that sounds reasonable.