fix(cline): close a stripped block at its own closing tag

`strip_environment_details` and `extract_feedback` in
src-tauri/src/parsers/cline.rs each located a block's opening tag and then
searched for the closing tag from the start of the whole message. Cline wraps
what the user typed inside these same markers, so a message that quotes one of
them puts a closing tag ahead of the block it appears to close.

When `</environment_details>` appears before the real `<environment_details>`,
`result[..start] + result[end..]` splices the opening tag back into the result
and returns a longer string than it was given, so `while let Some(start) =
result.find(...)` never ends: `get_conversation` for that Cline task loops
forever and grows the string without bound. The `<task>` loop has the same slip
and reads `result[inner_start..close]` with `close < inner_start`, which panics
on the reversed range. `extract_feedback` was already guarded, so it dropped the
feedback instead of crashing.

Each closing tag is now searched in the slice after its own opening tag, which
also makes both loops strictly shrink the string. Well-formed messages parse
exactly as before, including nested wrappers and unclosed openers.

Separately, the `# task_progress RECOMMENDED` block ended at the next `\n<`
whenever there was one, falling back to `\n#` only when there was not, so a
markdown heading between the block and the next tag was deleted along with the
block. It now ends at whichever boundary comes first, which is what "next
section" meant.

cline.rs had no unit tests; this adds a module covering all four cases plus the
well-formed, nested and unclosed shapes.