IDE foundation: establish cold/warm/incremental latency and memory baselines

[PhysShell]

Parent: #250
Recommended tier: medium/local-agent
Can begin after: #251
Should inform: #262, #264, #265

Goal

Create a reproducible performance and latency baseline for the current Owen pipeline and the emerging Rust core before introducing LSP/incremental architecture or declaring a cutover performance win.

The primary IDE metric is edit-to-diagnostic latency, not a vague batch multiplier.

Workloads

Record representative workloads for:

1. minimal .own file;
2. medium .own module;
3. corpus batch;
4. single C# file through Roslyn extractor → OwnIR → core;
5. representative .csproj;
6. representative multi-project .sln;
7. selected large real-world solution;
8. five pinned OSS repositories where practical.

Pin source commits and exact commands.

Measurements

Measure separately where possible:

• process startup;
• frontend/Roslyn extraction;
• OwnIR serialization and parse;
• bridge/lowering;
• analysis;
• report/SARIF rendering;
• end-to-end wall time;
• peak RSS;
• allocation/heap profile for selected workloads;
• repeated warm run;
• no-op recheck;
• single-file edit recheck;
• diagnostic publication latency proxy.

For the Rust path, do not benchmark incomplete placeholders as if they represent the final production route. Clearly mark unavailable stages.

Method discipline

• Use pinned hardware/runtime/toolchain metadata.
• Record warm-up policy.
• Separate cold and warm runs.
• Report distributions or repeated-run statistics, not one flattering number.
• Keep batch and IDE-oriented measurements distinct.
• Include raw machine-readable results.
• Profile before recommending optimizations.

Outputs

Add:

• a methodology note;
• machine-readable baseline data;
• scripts/commands that reproduce measurements;
• a stage-by-stage timing table;
• explicit latency budgets proposed for .own LSP and C# hybrid host;
• a list of dominant costs confirmed by profiling.

Guardrails

• No optimization PR in this issue.
• No allocator/interner/rayon change based only on intuition.
• No claiming Rust speedup from solver-only microbenchmarks while excluding extraction or rendering.
• No hidden use of different inputs between engines.
• Do not add unstable benchmarks as mandatory PR gates until variance is understood.

Acceptance

• Cold, warm and no-op/edit-oriented baselines are documented.
• End-to-end stages are separated sufficiently to locate bottlenecks.
• Raw data and reproduction commands are committed.
• Proposed IDE latency budgets are explicit.
• Results inform P-022 step 8: Rust-default cutover, rollback gate, and Python distribution removal #262 cutover and IDE MVP: ship a Rust .own LSP with broken-code tolerance and cancellation #264/IDE vertical: hybrid C# host with Roslyn semantic extraction and Rust core #265 design.
• No production behavior changes.