Decide how Knowledge mode handles WP global styles

## Goal

Cortext's editing theme paints the shell chrome in light or dark today. Once we extend it into the canvas iframe, the question is what happens to the WP global styles blocks rely on. Blocks consume `--wp--preset--*` tokens for color, typography, and spacing. Pick a model for how the Cortext editing theme interacts with theme.json and the user's Site Editor customizations.

## Scope

Walk through three options and pick one:

* **Theme globals through, Cortext chrome only.** The canvas iframe keeps the active theme's global styles and Site Editor customizations. Cortext tokens only paint chrome and Cortext blocks. Blocks render with the user's theme palette.
* **Cortext globals replace theme globals.** Knowledge mode emits a full Cortext preset bundle (palette, typography, spacing, block defaults). Blocks consume Cortext values regardless of the active theme. User's Site Editor customizations are not visible in Knowledge mode.
* **Hybrid.** Knowledge mode emits a minimal Cortext preset set derived from Cortext tokens, enough for blocks to render coherently with chrome. Most of theme.json is otherwise ignored.

For each option, capture how typical blocks render, how Site Editor customizations behave, the design footprint Cortext takes on, and where each model strains at the edges.

## Out of scope

* Implementing the chosen option.
* Site Preview mode behavior; Site Preview always uses the active theme's globals.
* Public-side rendering.

## Acceptance criteria

* A model is recorded with rationale.
* The implementation ticket is filed against this one.

Start by reviewing Knowledge mode's canvas iframe behavior and WordPress theme.json/global styles flow. Compare the three models for typical block rendering, Site Editor customizations, Cortext's design footprint, and edge cases. Done means recording a rationale for one model and filing the implementation ticket.

Written by the indexing model from the issue text.