exp(https): pool queue growth test + static vs growable ring A/B

[gg582]

Experiments for the HTTPS pool queue change that was pushed directly to dev (8d5a5958) and cherry-picked to main (e7568313). This PR only adds a regression test and the write-up; it does not change src/.

Results (details in docs/performance/https-pool-dynamic-queue.md)

Each result compares two non-ASan builds from the same tree that differ only in https.c. Server: CWIST_C1M_MODE=1.

	static ring (before)	growable ring (after)
RSS added by https_pool_init() alone	+98 484 KiB	+176 KiB
.bss of the server binary	100.9 MB	0.2 MB
idle RSS, 4 workers + master	~422 MB	~29 MB
keep-alive req/s, wrk -c64, 3 rounds	159.5k / 155.7k / 146.0k	162.4k / 138.3k / 153.6k
churn req/s, ab -c64, new TLS conn each	840 / 798 / 857	841 / 766 / 842
3000-connection burst	3000/3000 in every round	3000/3000 in every round
6000-conn burst, 1 worker, 2 pool threads	6000/6000, 6.61 s / 6.49 s	6000/6000, 6.60 s / 6.46 s; ring grew to 4096 (gdb)

Throughput and latency are within run-to-run noise. The memory saving is about 96 MiB per process that starts the pool.

Test

tests/test_https_pool_queue.c (new make test_https_pool_queue target, also added to the test list). One pool thread is held in a handler while 5000 tasks queue behind it, so the ring wraps first and then grows while wrapped. Every task must run exactly once, in submission order. It passes under ASan + UBSan.

Open questions, not decided here

• Shrinking: the ring keeps the capacity of its largest burst.
• Lock-free queue: not explored, and lock contention was not measured.