fix(search): derive snippet spans from the matched bytes - #1643

The three content-search snippet paths end a match at start+len(pattern). The start offset is already computed the careful way, rune by rune over the body, so a case mapping that changes UTF-8 length cannot shift it, but the end is taken from the pattern. Simple folding maps U+212A KELVIN SIGN, three bytes, to k, one byte, so a body holding the long form ends the span two bytes inside that rune, and a pattern holding it ends the span two bytes past the match.

snippetBounds and its PostgreSQL and DuckDB twins pad the span by 60 bytes and snap only the padding edges back to a rune boundary. Their loops stop when they reach the span, so none of them can repair a span that is not aligned. The 60-byte radius means no snippet is visibly wrong today, but rune alignment is the precondition those helpers and secrets.RedactWindow are written against, and the three copies of the same end expression are the kind of thing that drifts.

CaseInsensitiveIndex becomes CaseInsensitiveSpan: it returns the byte range the match actually covers in the body plus whether one was found, and each backend windows that range instead of recomputing an end from the pattern. Everything ASCII, which is nearly every query, gets the identical span it got before.

One behavior change comes with it. A miss now yields an empty span at the start of the body rather than a pattern-length one, so the fallback window is up to len(pattern) bytes shorter on its right edge. The substring paths reach that branch only if SQL LIKE/ILIKE matched where the Go search did not, and the Go fold is the wider of the two, so it is unreachable there; FTSSnippetRange already returned 0, 0 for its own start fallback.

Reviewer attention is best spent on CaseInsensitiveSpan and foldPrefixEnd in internal/db/search_content.go. The PostgreSQL and DuckDB call sites are the same two-line substitution, and I could not exercise their suites locally since both need services I do not have set up.