expr: bound the memory a webhook CHECK may allocate (SQL-431)

[mtabebe]

Problem:
A webhook CHECK is a user defined expression that environmentd evaluates once per in-flight request, and nothing bounds what it could allocate.

The webhook path caps request count (500) and body size (5 MiB), but the evaluation's footprint is per-request and was bounded only by MAX_STRING_FUNC_RESULT_BYTES, a 100 MiB per-call ceiling sized for a cluster.

That ceiling multiplies by request concurrency, so a CHECK doing length(repeat(body, 20)) >= 0 turned 150 concurrent 5 MB posts into 8.7 GiB of RSS, growing with the number of clients.

Solution:

• Give RowArena an optional budget and build the validation arena with one, defaulting to 20 MiB via a new dyncfg, webhook_validation_memory_budget_bytes.
• Functions that can predict their result size consult max_string_func_result_bytes, which narrows the constant to the arena's remaining budget, so an over-budget result is never allocated at all.
• Everything else is caught by a post-call check in the evaluator, which covers functions with no ceiling of their own.
• Stop copying an owned result into the arena. String and Vec outputs went through push_string/push_bytes, which copied and dropped the original.

An unbudgeted arena, which is every arena in a dataflow, is unaffected

Testing:

• New integration test webhook_validation_memory_budget: a 2 MiB body that amplifies past the 20 MiB default is refused with 400, a smaller body through the same source succeeds, and raising then lowering the dyncfg flips the result both ways
• New expr unit tests cover the pre-check and post-call paths
• New unit tests cover the arena bookkeeping and buffer adoption