feat: [AR-403] Anchor persistence (and optional sharing)

[MAILLOTNathan]

AR-403 — Anchor persistence (and optional sharing)

Milestone: AR Ready · Phase: 5 · Spatial anchors
Type: feature · Template: .github/ISSUE_TEMPLATE/feature-request.md
Roadmap: docs/AR_ROADMAP.md §9 (AR-403)

Optional (not mandatory): low priority / stretch goal. Core AR does not
depend on this issue; it can be deferred or dropped without blocking the AR
Ready milestone.

Context

Describe what problem is encountered and why it has to be fixed

MR content anchored to the real world should survive an app relaunch. Without
persistence every launch loses placed content.

Priority level

Add enough elements that shows how much this feature is important to be done

Low — not mandatory. This issue is a stretch goal: the mandatory AR phases
do not require it. Implement only after the required phases are done and if
capacity allows; it can be dropped without blocking the AR Ready milestone.

Description

Explain what this feature should do

• Persist/erase anchors (uuid → storage) and load persisted anchors across app
  launches (XR_FB_spatial_entity_storage family per the audit).
• Store the mapping between app content and persisted anchor uuids so content can
  be re-placed on load.
• Follow-up (separate, not part of this issue): cross-device / colocated
  anchor sharing.

Possible conflicts

Talk about actual behavior and if it can affect another side of the code (so we can be careful while coding it)

Depends on stable anchor identifiers (AR-402) and on storage permissions;
versioning of persisted data must be considered.

Definition of done (Acceptance criteria)

• An anchor persisted in session A is found by a query in session B.
• Persisted anchors reload and re-lock to the real world on launch.
• Erase removes the anchor from storage.

Affected files & areas

• headers/evan/openxr/XrSpatialAnchors.hpp
• sources/openxr/XrSpatialAnchors.cpp
• Engine/app-facing persistence keys

Depends on

• AR-401, AR-402