Add production Memory Editor engine and runtime UI

[H3nb]

Summary

This PR consolidates the full Memory Editor milestone previously split across PR #115 and PR #116. PR #117 is now the single authoritative review/work branch for this feature.

It includes both the remote native search foundation and the runtime Memory Editor UI/write layer:

• one authoritative :memory_engine service with a native process_vm_readv() scan core;
• target-local resident-range collection from the MIDlet process with runtime-generation scoping;
• known and unknown searches, primitive value types including Auto, relative/delta predicates, previous-vs-initial comparisons, bounded history/Undo, cancellation, and result paging;
• CandidateId-based result identity, refresh, remove/keep, Advanced Group Search, guarded edit, Watch, labels, and fail-closed Freeze modes;
• translucent Compose runtime overlay inside MicroActivity, reachable from the existing runtime Back menu;
• grouped Auto aliases by live address while preserving explicit type-level selection for writes;
• English/Indonesian resources, portrait/landscape handling, insets, dark theme, accessible touch targets, system Back, and physical/remapped Back;
• complete Phosphor icon attribution for the vendored vectors.

Core scaling work

The combined implementation now includes the main scaling improvements identified during the architecture audit:

• small candidate refinements use exact direct reads while large address-ordered sets reuse a 256 KiB remote chunk;
• Auto/Unknown candidates are ordered for locality and query dispatch is resolved outside the inner candidate loop;
• result states build sparse checkpoints every 256 logical addresses so deep paging jumps near the requested page instead of walking from the beginning;
• relocation recovery for live/write operations batches the bounded recovery set into one resident-memory scan instead of rescanning the target once per candidate;
• known-search relocation recovery indexes only old (type, identity) keys that actually need recovery;
• Advanced Group Search uses the rarest term as a prefilter while preserving first-term window semantics;
• candidate identity is captured from already-read scan chunks where possible, reducing extra remote reads;
• duplicate CandidateIds are rejected rather than silently deduplicated;
• CandidateId validation is single-pass over current candidates/watch state instead of ids × candidates scans;
• passive refresh never replaces an already-established identity fingerprint merely because an address remains readable.

Safety and containment

• both services are non-exported;
• target generation, not PID alone, scopes all operations;
• no arbitrary raw-address write API and no unlimited Edit All path;
• multi-edit and Freeze setup are capped at a provisional 32 explicit candidates;
• writes require stable identity, expected-value validation, exact-width same-page/aligned write, readback, and best-effort restore on failure;
• relocation recovery requires unique type/value/identity matches; zero matches become Lost and multiple matches become Ambiguous;
• empty, duplicate, stale, foreign, or non-Watch CandidateId sets fail closed;
• Watch state is independent from search history and survives search clear/Undo until runtime-generation loss;
• Freeze runs on the single :memory_engine worker and independently pauses unsafe records;
• no scan/recovery work runs on Android UI/input callbacks;
• candidate/snapshot/resource limits never publish partial search state.

Validation

The former PR #115 head passed Android CI. This consolidated PR is now the validation target for all further work.

Current combined head: f9145942fb93ab2ec4879d5b8307b4dacbd28713.

Android CI run #906 was triggered against this exact combined head through PR #117 and is the current integration validation run.

Physical-device validation remains required before stable release, especially:

• Android 16 capability probe;
• Bounce / Green Farm search-refine-edit workflows;
• multi-edit partial-failure behavior;
• relocation behavior;
• Freeze identity-loss behavior;
• RSS/latency soak testing on large candidate sets and Unknown snapshots.

Current design choices still provisional

• candidate limit: 2,000,000 typed candidates;
• Unknown snapshot budget: 96 MiB;
• history budget: 192 MiB;
• relocation-tracked search limit: 25,000 candidates;
• write/recovery bound: 32 candidates;
• Watch limit: 128 candidates;
• Freeze cadence: 750 ms.

These should remain conservative until physical profiling proves safe higher or lower defaults.

Supersedes

• PR Add production Memory Editor search engine #115 — Memory Editor native/service foundation
• PR Add safe Memory Editor controls and runtime UI #116 — Memory Editor runtime UI, identity, edit/watch/freeze layer

All further review, fixes, benchmarks, and feature work for this milestone should happen in PR #117.