Fix lastWrittenLsnCache eviction order

[mingjiegao]

Problem

lastWrittenLsnCache is expected to stay within neon.last_written_lsn_cache_size. However, when the cache is full, inserting before eviction can require one extra shared hash entry.

With a fixed-size shared hash table, this can fail with out-of-shared-memory.

Summary

Fixes #12905.

This PR changes lastWrittenLsnCache so that when a new entry needs to be inserted and the cache is already full, an existing entry is evicted before inserting the new one.

Previously, the code inserted the new entry first and evicted afterwards. This could temporarily require neon.last_written_lsn_cache_size + 1 hash entries.

Fix

For new keys, the code now ensures capacity before calling HASH_ENTER:

1. Check whether the entry already exists.
2. If it does not exist and the cache is full, evict an existing entry first.
3. Insert the new entry only after capacity has been made available.

Testing

• Manually reproduced the issue by setting neon.last_written_lsn_cache_size = 10 and adding HASH_FIXED_SIZE to the ShmemInitHash call for lastWrittenLsnCache.
• Verified that after the fix, the same workload no longer fails with out-of-shared-memory.

I did not add an automated test because the failure depends on shared hash table sizing and concurrent workload behavior. I would appreciate guidance on the best test location for this case.