scrollbackLimit is documented as lines but interpreted as bytes by WASM

### Description

The `scrollbackLimit` config option is documented and typed as a line count, but the WASM terminal internally interprets it as a byte count. This mismatch means the actual scrollback capacity is drastically smaller than expected.

### Details

**JS side** (`lib/types.ts`):
```typescript
export interface TerminalConfig {
scrollback_limit: number; // Number of scrollback lines (default: 10,000)
// ...
}
```

And in `lib/ghostty.ts`:
```typescript
// scrollback_limit (u32)
view.setUint32(offset, config.scrollbackLimit ?? 10000, true);
```

The `GhosttyTerminalConfig.scrollbackLimit` field and `Terminal` constructor's `scrollback` option both treat this as a line count. The default is `10000`, suggesting 10,000 lines of scrollback.

**WASM side**: `Terminal.init()` / `Screen.init()` interprets `max_scrollback` as **bytes**. 10,000 bytes is only enough for a handful of rows depending on column width and cell size, not 10,000 lines.

### Impact

- Users setting `scrollback: 10000` (the default) get far less scrollback than expected
- The small buffer causes pages to wrap frequently, which can trigger viewport corruption when the viewport spans multiple pages (see #139)
- Workaround: pass a very large value (e.g., `5_000_000`) to approximate a reasonable scrollback depth

### Expected behavior

Either:
1. The JS layer should convert line counts to bytes before passing to WASM (e.g., `lines * cols * CELL_SIZE`), or
2. The documentation and type comments should clearly state the unit is bytes, and the default should be adjusted accordingly (native Ghostty uses 10MB)

### Related

- #139 — viewport corruption is exacerbated by the undersized scrollback buffer
- #133 — draft PR that includes a comment fix noting this discrepancy