feat: per-host `max_cols`/`max_rows` cap on the size control asks the remote for (#49)

* feat: per-host max_cols/max_rows cap on the size control asks for (#47)

Control is authoritative on the remote — the server resizes the remote pty
to whatever the controlling client asks for, beating even a larger live
client over there. `connect()` and the SIGWINCH handler both asked for
`term_size()` unconditionally, so on a host with `always_control = false`
(a laptop with its own display and a human at it) every control escalation
reflowed that machine's pane to the local window's geometry, and releasing
control an hour later reflowed it back.

Observe already avoids this via `size_fixed` / `observe_size()`. Control had
no equivalent and `HostConfig` carried nothing about size, so the only
workaround was to physically resize the local terminal until `stty size`
matched — which reverts the moment that window is maximised again.

Add optional `max_cols` / `max_rows`, global with a per-host override, in the
same shape as `always_control`:

    [hosts.macbook]
    target = "macbook"
    always_control = false
    max_cols = 212
    max_rows = 58

They are ceilings, not demands: a local pane smaller than the cap is left
alone. Unset by default, so an uncapped host's streamer argv and requested
size are byte-identical to before and headless remotes keep filling the pane.
A cap of 0 is treated as unset rather than a clamp to nothing, matching how
an empty remote_bin means "auto".

The clamp lives in a free `cap_size()` so the arithmetic is testable without
an App, and is applied in both places that send a control size — the initial
connect and the window-resize path — so dragging the local window can't push
a capped host past its ceiling either.

Closes #47

* fix: reject a zero size cap on the CLI and warn instead of dropping it silently

---------

Co-authored-by: niko <nikokristanto24@gmail.com>