fix(core): register RDMA-fetched blocks to MetaServer after prefetch

[xiaguan]

Problem

RDMA prefetch pulled blocks into the local read cache but never re-advertised them to the MetaServer. Once the original holder evicted those blocks (unregister), the MetaServer believed nobody owned them — even though the fetcher still held valid, RDMA-servable copies in pinned RAM.

Scenario that breaks:

1. Node A saves blocks → registered to MetaServer as owned by A
2. Node B RDMA-READs them into local pinned RAM → not registered (the bug)
3. Node A evicts via LRU → try_unregister → MetaServer thinks nobody owns them
4. Node C queries MetaServer → no hit → cannot discover blocks on Node B, even though they exist and are servable

Fix

After RDMA prefetch completes and blocks are inserted into the read cache, the fetched block hashes are registered to the MetaServer via the same fire-and-forget path (try_register_namespace) used by the normal save path.

SSD prefetch is intentionally skipped: those blocks were already registered by this node's own save path, and eviction explicitly unregisters them — the SSD case is internally consistent.

Changes

• pegaflow-core/src/storage/prefetch.rs: PrefetchScheduler now holds an optional MetaServerClient. In poll_existing, after read_cache.batch_insert, RDMA-sourced blocks are registered to the MetaServer.
• pegaflow-core/src/storage/mod.rs: pass metaserver_client into PrefetchScheduler::new.
• pegaflow-server/tests/p2p_rdma.rs: added wait_for_metaserver_ownership helper and a test assertion verifying the fetching node re-registers the blocks it pulled.

Verification

• cargo build -p pegaflow-core --no-default-features --features cuda-13,rdma — passes
• cargo clippy -p pegaflow-core --no-default-features --features cuda-13,rdma — clean
• cargo test -p pegaflow-core --no-default-features --features cuda-13,rdma -- storage::prefetch — 2/2 pass
• All pre-commit hooks pass
• p2p_rdma integration test compiles (requires RDMA hardware to run)