[quality] Add latency and large-file performance checks

[owainlewis]

Goal: Add lightweight performance checks so Cortex protects input latency and large-file behavior as the editor grows.

Context: Cortex’s product promise is speed.
Without repeatable checks, regressions in render cost, search cost, highlighting cost, or buffer edits can slip in while adding windows and terminal panes.
This should be small and local, not a benchmarking framework project.

Proposed approach:

• Add focused tests or ignored benchmarks for representative buffer editing, visible-line rendering, highlighting, and search paths.
• Use deterministic generated files or in-memory buffers rather than committed large fixtures.
• Capture rough budgets in comments or docs so future work knows what matters.
• Keep checks runnable on macOS developer machines without special services.
• Prefer stable regression signals over exact nanosecond claims.

Acceptance criteria:

• There is a documented way to run local performance checks.
• Checks cover insertion/deletion in a large rope-backed buffer.
• Checks cover rendering a viewport from a large file.
• Checks cover highlighting visible lines for at least Rust and Markdown.
• Checks cover simple search over a large buffer.
• Normal cargo test stays fast.
• Any slower checks are clearly marked and easy to invoke.

Verification:

• Run cargo test.
• Run the new performance check command documented by the issue.
• Confirm the checks do not require network access or non-repo fixtures.

Out of scope:

• CI performance gates.
• Exact universal latency budgets.
• Profiling every command.
• Rewriting rendering or highlighting as part of this issue.