Improve layout flexibility

Ran into some issues being able to get a more expressive full-screen layout. AI / Claude notes for things that can be improved with the grid / layout:

# Layout improvement notes

Collected while doing a design pass on `docs/examples/fullscreen-dashboard.ipynb`
(a controls-rail + lonboard-map + chart layout inside `Fullscreen`). Observations
only — none of this is implemented. Ordered roughly by impact.

## 1. Grid: equal columns only

`grid/widget.py` has `columns = traitlets.Int(2)` and `grid/src/index.ts` hard-codes
`repeat(N, minmax(0, 1fr))`. There is no way to express the most common dashboard
shape — a narrow control rail beside a wide map (`320px 1fr`), or a cell spanning
two columns. The workaround in the example (put the chart in the rail so the 50/50
split doesn't leave a dead half-column) works but shouldn't be necessary.

Smallest fix: widen `columns` to `Union([Int(), Unicode()])`; when it's a string,
pass it straight through to `gridTemplateColumns`. ~4 lines across widget.py and
index.ts. Spans would need a per-child wrapper or a `spans=[...]` trait — bigger
API question.

## 2. Chart: fixed pixel width only

`Chart.width` is `Int` (px). `.manywidgets-chart` has `max-width: 100%`, so a chart
can shrink but never fill a wider container. The example exploits this by
oversizing (`width=1100` → the column caps it), which works because Chart.js is
`responsive: true` — but it's a non-obvious trick. Supporting `width=None` (or
`"100%"`) meaning fill-container would make charts compose into layouts naturally.
Same question applies to `height` eventually (fill a fixed-height cell).

## 3. Row/Column: no justify, no per-child sizing

`row/`, `column/` expose only `gap` and `align`. Cells are `flex: 0 1 auto` with no
way to set grow/basis per child, so a `Row` collapses children without intrinsic
width (lonboard maps — already noted in `docs/examples/layout.ipynb`). A `justify`
trait and some per-child flex control (`Row(a, b, flex=[0, 1])`?) would cover most
gaps; until then Grid is the only reliable side-by-side container.

## 4. FilterBinder chip / LayerToggle theming

- `FilterBinder` renders a status chip styled via inline `el.style.cssText`
(`lonboard/filter_binder/src/index.ts`) — unoverridable, no `visible`/compact
trait, and it must stay mounted for static export. In a polished dashboard it
reads as debug output. A `show_status=False` mode that renders (say) a 0-height
element while keeping the JS alive would fix it.
- `lonboard/layer_toggle` never calls `applyThemeVars` and hardcodes its colors
and sizes, so it ignores `theme=`/`style=` and the `--mw-toggle-*` tokens the
core `Toggle` honors. Visually inconsistent next to themed controls.

## 5. Fullscreen: alt layout can't opt into fill-height

Only the no-alt slot path gets the stretch rules (`.mwfs__content > .mwfs__slot`);
a `fullscreen=` layout is `height: auto` and the panel scrolls. Fine as a default,
but a dashboard usually wants "fill the screen, no scroll" — some opt-in (or a
documented `height="70vh"`-style recipe, which is what the example uses) would
help. Also the overlay's `padding: 24px` is hardcoded in `fullscreen/style.css`
where the panel padding is already tokenized — could be a `--mw-*` token too.

## 6. Fixed widget margins

Nearly every widget wrapper carries `margin: 10px 0` in its own style.css.
Containers can only add space (`gap`), never remove it, so tight layouts bottom
out at ~20px rhythm. A `--mw-widget-margin` token (or containers zeroing child
margins and owning spacing via gap) would give real control.

## Aside: what DOES compose well today

`style=` on any themable widget cascades `--mw-*` tokens to descendants across
shadow boundaries — e.g. `Fullscreen(..., style={"--mw-control-max-width": "100%"})`
retunes every control card inside the overlay in one place. This is a genuinely
good lever; worth documenting more prominently in the theming guide.

---- end AI notes -----

@dzole0311 I think some of the flexbox stuff, etc. is beyond me to know exactly what we should do here. Most of the AI notes make sense, but would like to get a sanity check if these seem sensible to do or if we should re-look at some of the grid / layout stuff in a more fundamental way.

Start by reading the layout implementation in grid/widget.py and grid/src/index.ts, then review the related fullscreen, row/column, chart, FilterBinder, and layer_toggle files named in the notes. First get a maintainer decision on which proposal is in scope; done should mean one selected layout improvement is specified and implemented without taking on the other API questions.

Written by the indexing model from the issue text.