Layer-purity: remove studio_web_* vendor coupling from the generic chat widget

## Problem

`frontend-agent-chat` is the **generic** floating agent-chat widget — it must not know about any specific downstream vendor/consumer. But `src/AgentChat.tsx` currently hardcodes Studio Web specifics directly into the generic layer. Per the platform RULES.md layer-purity test (`grep -riE 'studio' in a layer that claims to be generic == violation, even in field names, examples, or copy`), this is a layering violation.

## Current violations (`src/AgentChat.tsx`)

| Line | Violation |
|------|-----------|
| ~1069 | `studio_web_propose_questions: renderQuestionCard` — vendor tool name as a renderer key |
| ~1070 | `studio_web_start_generation: renderGenerationCard` — vendor tool name as a renderer key |
| ~725 | `renderGenerationCard()` — a studio-only "generation in progress" card living in the generic widget |
| ~738 | Hardcoded copy: `"Studio Web is preparing your WordPress site from the captured site brief."` |
| ~337 (`src/agent-chat.css`) | `.frontend-agent-chat__tool-card--generation.has-error` — styling for the studio-only card |

## Why now

PR #63 (https://github.com/Extra-Chill/frontend-agent-chat/pull/63) adds a **generic** `present_question` renderer key that maps to the already-generic, tool-name-agnostic `renderQuestionCard`. That's the correct pattern and the seam this issue should build on: renderer mapping should be **config/registration-driven**, not a hardcoded object containing vendor tool names.

## Proposed fix

1. Make `toolRenderers` extensible from outside the generic layer — e.g. accept a renderer map (or a registration filter/prop) from the consumer so vendors register their own tool-name → renderer mappings. The generic widget ships only generic keys (`present_question`, `edit_post_blocks`, `replace_post_blocks`, `insert_content`, `artifact_*`).
2. Move the studio-specific `renderGenerationCard` + its copy + its CSS into the studio consumer (wherever `studio_web_start_generation` is emitted), registering it via the new seam.
3. Remove `studio_web_propose_questions` once studio is migrated to emit/ map `present_question` (or registers its own mapping to `renderQuestionCard` via the seam).
4. Confirm `grep -riE 'studio' src/` returns zero matches in the generic layer afterward.

## Acceptance criteria

- [ ] `grep -riE 'studio' src/` in `frontend-agent-chat` returns no matches.
- [ ] Studio Web still renders its generation-progress card and question card (via the consumer-side registration seam, not the generic layer).
- [ ] `npm run build` passes.
- [ ] No new vendor names introduced in the generic layer.

## Context / dependencies

- Builds on the generic `present_question` key from PR #63.
- Related work: roadie's `present_question` tool (Extra-Chill/extrachill-roadie#37) is the first non-studio consumer of the generic question card, which is exactly why the generic seam matters.

Start with src/AgentChat.tsx and src/agent-chat.css, then inspect PR #63's present_question renderer and the consumer that emits studio_web_start_generation. Run grep -riE 'studio' src/ and npm run build. Done means the generic layer has no vendor matches while Studio Web still renders its generation and question cards through the consumer-side registration seam.

Written by the indexing model from the issue text.