[codex] Cache prepared get_blocks results per request

[Fellan-91]

Summary

• cache prepared get_blocks() results for the current PHP request
• keep $no_cache = true as a full bypass and clear the request cache when it is used
• clear the request cache when programmatic blocks are added, removed, or when the existing block cache is cleared
• document the performance fix in the changelog and readme

Problem

Sites that register many blocks programmatically with lazyblocks()->add_block( $block_config ) can call get_blocks() repeatedly during a single request. Each call prepared the same user blocks again, so pages with 50+ blocks could spend significant time rebuilding identical block data.

Solution

The plugin now stores the prepared get_blocks() result in an in-memory request-level cache keyed by db_only and keep_duplicates. The public lzb/get_blocks filter still runs on every return, while the heavier lzb/block_data preparation work is reused within the request.

$no_cache = true continues to bypass the cache and now clears any prepared request cache so forced rebuilds remain fresh.

Validation

• npm run test:unit:php -- --filter BlockRegistrationTest
• npm run test:unit:php
• checked compatibility against Lazy Blocks Pro relationship rebuilds
• manually profiled a LocalWP site with the Pro core patched temporarily: repeated lzb/block_data preparation dropped from about 380 calls per request to about 19

Note: PHPUnit still reports existing config validation warnings for processUniqueFiles and <filter>.