fix(scanner): don't leak start_tag across serialize/deserialize

[lucieleblanc]

Problem

I was running macOS leaks on a long-running host that parses many .sql files and noticed a growing set of allocations rooted in tree_sitter_sql_external_scanner_deserialize that grew linearly with the number of parses.

I think the external scanner's _serialize/_deserialize pair mishandles the LexerState.start_tag for strings delimited by dollar-sign tags instead of quotes:

• _serialize frees and nulls start_tag after copying it into the snapshot buffer. If tree-sitter calls scan() on the same scanner instance again, it sees a NULL start_tag and can no longer match the pending dollar-quoted-string end tag.
• _deserialize assigns to start_tag without freeing whatever the state already owns, leaking the previous allocation every time saved state is restored.

Solution

Free any existing start_tag at the top of _deserialize instead of _serialize, using the same pattern as _destroy.

Testing

After this fix, running leaks on the same program shows no more live allocations from tree_sitter_sql_external_scanner_deserialize.

I added a corpus entry to assert the AST shape and guard the named-tag parse against future regressions. It produces the same AST as the previous test, but uses named tags ($body$ ... $body$ instead of $$...$$).