Refactor: clarify global/local naming in get/put and match paths

[XingLiu1]

Background

There are several different meanings of global and local in the cache-engine code today:

• GlobalCacheEngine means the request-level multi-tier control plane.
• _get_impl_global / _put_impl_global mean the get/put path that includes the REMOTE tier.
• _get_impl_local / _put_impl_local mean the CPU/SSD path, but this path may still involve peer CPU/SSD behavior when P2P is enabled.
• match_all / match_local aggregate across different tier sets, and HierarchyLRCacheEngine also has its own match_all / match_local semantics for distributed/local index lookup.

These are all valid concepts, but they are not the same concept.

Problem

The overloaded naming makes the control flow easy to misread:

• global can mean the class-level control plane or the remote-tier transfer path.
• local can mean no REMOTE tier at the request planner level, but not necessarily no peer/remote data movement inside CPU/SSD P2P logic.
• The get/put implementation functions return large tuples containing graph state, callback state, buffer state, transfer counts, skipped blocks, and match results, which makes it harder to tell which layer owns which responsibility.
• Future remote/SWA/P2P changes are likely to touch these names and risk adding more semantic ambiguity.

Suggested direction

• Rename get/put implementation paths around the tier set they plan, not around global/local, for example:
  • _get_impl_with_remote / _put_impl_with_remote
  • _get_impl_cpu_ssd / _put_impl_cpu_ssd
  • or extract planner classes such as RemoteTierGetPlanner and CpuSsdGetPlanner.
• Rename match helpers to encode the tier set explicitly, for example:
  • match_cpu_ssd
  • match_cpu_ssd_remote
  • match_distributed_remote where appropriate.
• Add docstrings around HierarchyLRCacheEngine.match_all vs match_local to make distributed snapshot vs local-tree semantics explicit.
• Replace the large tuple returns from _get_impl_* / _put_impl_* with small dataclasses such as GetPlan / PutPlan / TierMatchResults.
• Separate routing, tier matching, allocation, graph planning, and ready/unlock callback construction where it reduces coupling.

Acceptance criteria

• Function names make it clear whether the REMOTE tier is part of the planned path.
• GlobalCacheEngine no longer shares the overloaded global vocabulary with remote-tier get/put implementation names.
• get() / put() routing remains behavior-compatible for these cases:
  • remote disabled
  • temp_cache_strategy.ignore_remote=True
  • remote enabled
  • P2P CPU/SSD enabled
  • KV sharing enabled
• Return values from get/put planner helpers are structured enough that field order mistakes are difficult.