Fix stale allocChunkLimit when recycling AllocSet

Hi,

While reading the memory context code, I found an issue with AllocSet’s recycling mechanism.

Looking at the code:
```
/*
* If a suitable freelist entry exists, just recycle that context.
*/
if (freeListIndex >= 0)
{
AllocSetFreeList *freelist = &context_freelists[freeListIndex];

if (freelist->first_free != NULL)
{
/* Remove entry from freelist */
set = freelist->first_free;
freelist->first_free = (AllocSet) set->header.nextchild;
freelist->num_free--;

/* Update its maxBlockSize; everything else should be OK */
set->maxBlockSize = maxBlockSize;

/* Reinitialize its header, installing correct name and parent */
MemoryContextCreate((MemoryContext) set,
T_AllocSetContext,
MCTX_ASET_ID,
parent,
name);
```

When recycling a context from the freelist, it only resets set->maxBlockSize without recalculating set->allocChunkLimit, while set->allocChunkLimit is derived from set->maxBlockSize.

Does this have a real impact? I verified it this way: I added a log to compare the retained allocChunkLimit with the expected allocChunkLimit, then ran “make check”. See the attached repro1.diff for this debug change, and repro1_result.txt, which shows a lot of hits at runtime, for example:
```
2026-10-16 13:20:12.174 CST client backend[66213] pg_regress/oidjoins LOG: EVAN: recycling AllocSet context "CachedPlanSource": maxBlockSize 8192 -> 8388608, allocChunkLimit retained 1024, expected 8192
```

AFAIK, when an allocation requests a size larger than set->allocChunkLimit, it goes to the system malloc(). Thus, a stale smaller allocChunkLimit may cause unintended malloc()/free() calls, which breaks the intended allocation policy.

Again, do some allocations really go to malloc() unintentionally? I added more logs and ran “make check”. See the attached repro2.diff and repro2_result.txt. There are also a lot of hits, for example:
```
2026-10-16 13:21:10.951 CST client backend[69075] pg_regress/event_trigger LOG: EVAN: AllocSet context "CachedPlanSource": allocation size 1328 wrongly takes malloc path; allocChunkLimit retained 1024, expected 8192
```

In the other direction, when the retained set->allocChunkLimit is larger than expected, allocations that should use dedicated malloc() blocks will be pooled, which leads to unexpected memory retention after pfree().

Once again, are there real hits? See the attached repro3.diff and repro3_result.txt. There are also a lot of hits, for example:
```
2026-10-16 13:40:37.168 CST client backend[73568] pg_regress/fast_default LOG: EVAN: AllocSet context "PortalContext": allocation size 2244 wrongly takes pooled chunk path; allocChunkLimit retained 8192, expected 1024
```

In summary, this bug doesn’t lead to memory leaks, but it breaks AllocSet’s intended allocation behavior: sometimes causing unexpected malloc()/free() calls, and sometimes unexpected pooling and memory retention.

The fix is straightforward. I extracted the allocChunkLimit computation into a shared helper and use it in both the creation and recycling paths. See the attached patch for details. Since this code is very old, the fix might be worth backpatching to all supported branches.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/