figterm paste handler panics with non-UTF-8 input (from_utf8_lossy length mismatch)

## Bug

The figterm paste handler in `crates/figterm/src/input/mod.rs` panics when pasting content with bytes that are not valid UTF-8:

```
thread 'kiro-cli-term-runtime-worker-7' panicked at crates/figterm/src/input/mod.rs:1774:56:
range end index 2258 out of range for slice of length 2256
```

This is a re-report of #2002 which was closed without a fix. The figterm crate was removed from this repo but the bug persists in downstream consumers (Kiro CLI v0.10.32).

## Root Cause

In `process_bytes`, the `Pasting` state handler computes bytes to advance using `pasted.len()` (the byte length of the lossy-converted UTF-8 string) instead of `idx` (the raw byte offset returned by `find_subsequence`):

```rust
let pasted = String::from_utf8_lossy(&self.buf.as_slice()[0..idx]).to_string();
self.advance_buf(pasted.len() + end_paste.len()); // BUG: pasted.len() >= idx
```

`String::from_utf8_lossy` replaces each invalid byte with U+FFFD (3 UTF-8 bytes), so `pasted.len()` can exceed `idx`, causing `advance_buf` to slice out-of-bounds.

## Fix

```rust
self.advance_buf(idx + end_paste.len());
```

Use the raw byte offset `idx` for buffer arithmetic. The lossy conversion is only needed for the event payload.

Verifica se crates/figterm/src/input/mod.rs è ancora presente, quindi esamina l’handler Pasting di process_bytes intorno alla riga indicata e la sua chiamata a advance_buf. Conferma che l’avanzamento del buffer utilizzi l’offset di byte grezzo restituito da find_subsequence e verifica che un input incollato con UTF-8 non valido non causi più un panic per accesso fuori dai limiti nel consumer downstream interessato.

Scritto dal modello di indicizzazione a partire dal testo della issue.