vttablet: BuildPermissions panics on a top-level VALUES statement

Not looking for external contributions on this one. We're already working in this area and intend to fix it ourselves. Please don't open a PR against this issue — it's filed to track the problem and record the analysis, not as an invitation. Comments and additional repro cases are very welcome.

Overview of the Issue

planbuilder.BuildPermissions in vttablet panics with BUG: unexpected statement type: *sqlparser.ValuesStatement when handed a top-level VALUES statement such as

VALUES ROW(1, 2), ROW(3, 4)
WITH t AS (SELECT 1) VALUES ROW(1)

The function's switch is commented as covering every statement type, and it has no case for *sqlparser.ValuesStatement.

Today this is not reachable in production: the tablet planner's Build has no plan for a VALUES statement either and returns invalid SQL before permissions are derived, so a client gets an error rather than a panic. It becomes a live panic the moment someone adds a VALUES plan to vttablet without also touching the permission builder. Since #21091 the permission walker already handles VALUES statements nested in derived tables and union arms, including their WITH clauses, so the top-level case should be a READER walk like a SELECT's.

Reproduction Steps

func TestValuesPermissions(t *testing.T) {
	stmt, err := sqlparser.NewTestParser().Parse("values row(1, 2)")
	require.NoError(t, err)
	require.NotPanics(t, func() { planbuilder.BuildPermissions(stmt) })
}

Binary Version

main at b805b51ec8 (2026-09-14).

Operating System and Environment details

Any; reproduced with the Go test above on linux/arm64.

Log Fragments

panic: BUG: unexpected statement type: *sqlparser.ValuesStatement