optimize snooze metadata updates and add benches

[bgentry]

Following up on #1157, this is another metadata update optimization aimed specifically at job snoozing when the metadata payload is large.

Snoozed jobs with large river:log payloads were still paying an extra full-blob rewrite in jobexecutor.reportResult. The code marshaled MetadataUpdates and then used sjson.SetBytes to increment snoozes, which re-encoded the entire JSON payload.

Change snooze handling to set snoozes directly in the res.MetadataUpdates map before marshaling. This keeps behavior the same while avoiding the second large copy. The method now funnels marshal logic through a small helper used by both snooze and non-snooze paths.

Add focused benchmarks for this hot path, including 256 KB, 2 MB, and 8 MB river:log cases with both old-style and optimized approaches. Extend driver benchmarks with large metadata cases for JobSetStateIfRunningMany and JobGetAvailable to track driver-side amplification in fetch and update paths.

Benchmark results

go test ./internal/jobexecutor -run '^$' -bench BenchmarkMetadataUpdatesBytesForSnooze -benchmem -count=1

Comparison uses:

• Before = marshal_plus_set_snoozes (old behavior)
• After = set_snoozes_in_map_then_marshal (new behavior)

Payload	Time Before (ns/op)	Time After (ns/op)	Time Delta	Mem Before (B/op)	Mem After (B/op)	Mem Delta	Allocs Before	Allocs After	Allocs Delta
log_256kb	724,336	689,045	-4.9%	543,119	271,046	-50.1%	6	6	0%
log_2mb	5,676,874	5,344,169	-5.9%	4,749,888	2,165,160	-54.4%	9	7	-22.2%
log_8mb	23,097,605	21,641,865	-6.3%	18,386,022	8,602,858	-53.2%	9	7	-22.2%

Net: this change gives a modest CPU win and a large memory win on snooze metadata updates, especially at larger payload sizes.