[chenBright]

What problem does this PR solve?

Issue Number: resolve

Problem Summary:

Traffic spikes can leave tens of thousands of bthread stacks cached in ObjectPool.
After concurrency drops, their resident pages remain allocated, keeping process
RSS high even when only a few hundred stacks are needed.

What is changed and the side effects?

Changed:

• Add a generic process_idle_objects API to ObjectPool. It processes idle
  global chunks outside the pool lock and retains processed chunks for reuse
  after regular free chunks.
• Reclaim idle SMALL, NORMAL, and LARGE stack pages with MADV_DONTNEED,
  preserving and guard pages. Rebuild the context on reuse, including after partial
  reclamation failures.
• Start one background thread named bthread_trim during bthread initialization and
  expose the bthread_stack_trimmed_count metric.

Single-run measurements with 50,000 stacks and 8 workers showed the following
process RSS changes after synchronous trimming:

Stack type	Before trimming	After trimming	Reduction
SMALL	1025.66 MiB	51.27 MiB	95.00%
NORMAL	3564.87 MiB	52.02 MiB	98.54%
LARGE	13136.81 MiB	53.37 MiB	99.59%

Side effects:

• Performance effects:

• Breaking backward compatibility:

---

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow Contributor Covenant Code of Conduct.