[FEATURE] Show the current project/codebase identity in the CLI UI by default (hard to tell sessions apart when working on multiple projects)

Problem

When running several Claude Code CLI sessions on the same PC — one terminal window (or tab/split) per project — it is hard to tell which project a session belongs to after switching windows. The prompt area itself carries no project identity by default, so you have to scroll back or run a command like pwd to be sure which codebase you are about to give instructions to.

This is risky as well as inconvenient: it is easy to type an instruction intended for project A into the session running on project B.

Use case

• Same PC, multiple projects in parallel (e.g. 3–4 terminal windows, each with its own Claude Code session)
• Frequent Alt-Tab / tab switching between them
• Each window looks identical: same header, same prompt — nothing on screen says which repo/cwd the session is bound to

Current workarounds (and why they are not enough)

• statusLine setting: works (I currently use a custom script that prepends the cwd basename + git branch), but it requires every user to discover the feature, write a script, and configure it per machine. Project identity feels like something that should be visible out of the box.
• Terminal window/tab title: related requests exist (#17951, #7229), but the title bar is easy to miss, is controlled by the terminal (not always visible in splits/multiplexers), and some environments override it.

Proposed solution

Show the project identity by default in the CLI UI, for example:

• Display the workspace directory name (and ideally the git branch) near the prompt input — e.g. as a default status line shown when no custom statusLine is configured, or
• Include the project name in the existing header/footer chrome persistently.

Any of these would make it immediately obvious which codebase a session is operating on when switching between windows.

Environment

• Claude Code CLI on Windows 11 (Windows Terminal / PowerShell)
• Also applies to macOS/Linux terminals — the problem is platform-independent