prai-roadshow-lab-1-starter: agents resolve different `google-adk` versions; consider a uv workspace

The lab-1 starter has six independent Python projects — the repo root, four agents, and
the web app — each with its own `pyproject.toml` and `uv.lock`, and no
`[tool.uv.workspace]`. The lockfiles were generated at different times and have drifted.

### The drift

Every one of them declares the same constraint:

```toml
"google-adk>=1.27.4,<2.0.0"
```

But the committed lockfiles disagree:

```
agents/orchestrator/uv.lock google-adk 1.28.1
agents/researcher/uv.lock google-adk 1.28.0
agents/judge/uv.lock google-adk 1.28.0
agents/content_builder/uv.lock google-adk 1.28.0
uv.lock (root) google-adk 1.28.0
```

Confirmed both by reading the lockfiles and by the installed `.dist-info` after
`uv sync` — and reproduced identically on Windows 11 and Ubuntu 24.04, so it is not a
platform or resolution artifact. It is committed state.

The orchestrator is the service that calls every other agent over A2A, so the coordinator
is the one component running a different ADK build from everything it coordinates.

To be fair to the current state: `a2a-sdk` is consistent at `0.3.22` everywhere, so this
is not wire-protocol incompatibility, and nothing observably breaks today. The concern is
that it drifted silently and nothing would report it if the gap widened — in a sample repo
whose subject is agents interoperating.

### Suggestion

A workspace at the root expresses the intent directly and makes the drift impossible:

```toml
[tool.uv.workspace]
members = ["agents/*", "app"]
```

One lockfile, one resolution, and `uv sync` at the root prepares every service.

### Secondary benefit

`run_local.sh` invokes `uv run` inside each agent directory, so a first run on a clean
clone performs five separate cold dependency installs in series before anything starts.
With a workspace that becomes a single sync.

(Disk is *not* the argument — uv hardlinks package content from its global cache, verified
via `fsutil hardlink list` / inode sharing, so the six venvs cost roughly one copy on
disk. The argument is drift and startup time, not space.)

### Minor, same file

The root `pyproject.toml` declares:

```toml
[tool.hatch.build.targets.wheel]
packages = ["frontend"]
```

There is no `frontend/` directory at the repo root — it lives at `app/frontend/`. Harmless
today, but it suggests the file was adapted from another template.

---

Environment: Ubuntu 24.04.4 (WSL2) and Windows 11, uv 0.12.0 / 0.12.2, Python 3.12.

Start with the root pyproject.toml, the five other project pyproject.toml files and uv.lock files, then inspect run_local.sh to understand how each service is launched. Configure the proposed uv workspace, correct the root package path if needed, regenerate the shared lockfile, and verify that root uv sync and run_local.sh prepare and start all services successfully.

Written by the indexing model from the issue text.