fix(tracer): skip leading SQL comments in default operation name

[obitech]

Fixes #63.

Queries that start with a SQL comment (sqlc's -- name: GetFoo :one prefix is the common case) made the default operation-name parser return -- for db.operation.name, and since v0.12.0 for the span name as well. The default parser now skips leading -- line comments and /* */ block comments before taking the first word. A user-supplied WithSpanNameFunc is unaffected and still sees the raw statement.

Second commit removes the go1.24 build constraints: go.mod requires 1.25, so the !go1.24 variant never compiled and the tags were always satisfied.

Benchmark

BenchmarkDefaultSpanNameCtxFunc, Apple M-series, -count 3 median. Zero allocations before and after.

Query	main (332afb9)	this PR	Result on main
SELECT ...	17.4 ns/op	20.9 ns/op	SELECT
-- name: GetFoo :one\nSELECT ...	8.9 ns/op	28.4 ns/op	-- (wrong)
/* name: GetFoo :one */\nSELECT ...	8.9 ns/op	34.1 ns/op	/* (wrong)

The plain case pays about 4 ns for the leading-whitespace trim and two prefix checks. The comment cases were only faster on main because they stopped at the wrong token.

Not in scope

• Nested /* /* */ */ block comments are not handled and fall back to UNKNOWN. Documented on the helper.
• A sqlc helper that extracts the query name (GetFoo) is a separate design question, since spanNameCtxFunc currently feeds both the span name and db.operation.name.

🤖 Generated with Claude Code

[costela]

do the string cuts cause a new allocation? I think they don't.
If that's the case, it may be a good idea to clone the string before returning, to avoid keeping a reference to the whole query. Otherwise we could keep large queries from being collected by the GC as long as the span is live.

I guess it depends if the string we see here is the "raw" query without template substitutions (from which we'd have a single copy in memory) or the templated query, from which we may have arbitrarily many. 🤔

Maybe it's premature optimization...

[bendiknesbo]

Spending 20-25 ns to get better span names seems worth it to me, and trying to optimize it should not be a blocker for getting this merged, in my opinion. :)

[danielbprice]

FWiW, I pulled this fix into my project to test it, and it worked as described. Excited to see this land.

[obitech]

I'd also say we merge this as is and see if we can further optimize this down the line, if needed. @costela any objections? Otherwise I'd merge it.