🧹 Extract DeveloperSettings from SettingsDialog

[tstapler]

🎯 What: Extracted the DeveloperSettings composable from SettingsDialog.kt into its own file DeveloperSettings.kt.
💡 Why: SettingsDialog.kt was growing too large. Extracting individual settings tabs/sections into their own functions is easy and highly isolated, and improves maintainability and readability.
✅ Verification: Ran read_file to verify file creation/deletion, and compileKotlinJvm to ensure the project still compiles correctly without syntax errors.
✨ Result: Improved modularity and readability of SettingsDialog.

---

PR created automatically by Jules for task 2446156439696602594 started by @tstapler

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[github-actions]

JVM Load Benchmark (Desktop)

Synthetic in-memory benchmark measuring load performance for the desktop (JVM) app.
Comparing 2c38dcd4 (this PR) vs dc94048f (baseline)
Graph config: xlarge — 230 pages

Metric	This PR	Baseline	Delta
Phase 1 TTI ↓	0ms	1ms	-1ms (-100%) ✅
Phase 2 background ↓	0ms	0ms	0 (0%)
Phase 3 index ↓	1ms	1ms	0 (0%)
Total ↓	1ms	2ms	-1ms (-50%) ✅
Write p95 (baseline) ↓	19ms	17ms	+2ms (+12%) ⚠️
Write p95 (under load) ↓	1ms	n/a
Jank factor ↓	0.05x	n/a
↓ lower is better

Flamegraphs (this PR)

**Allocation** — object allocation pressure (JDBC/SQLite churn)

Alloc flamegraph not available

CPU — method-level hotspots by on-CPU time

CPU flamegraph not available

Top allocation hotspots (this PR)

`37.5%` byte[]_[k] `9.5%` java.lang.String_[k] `5.8%` java.util.LinkedHashMap$Entry_[k] `5.7%` int[]_[k] `3.3%` java.lang.Object[]_[k]

Top CPU hotspots (this PR)

`96%` /usr/lib/x86_64-linux-gnu/libc.so.6 `1.6%` /tmp/sqlite-3.51.3.0-0c8b6aa4-3c83-4313-87d9-38d51b3526f1-libsqlitejdbc.so `0.5%` __libc_pwrite `0.4%` fsync `0.2%` SR_handler

[github-actions]

Android Load Benchmark

Instrumented benchmark on an API 30 x86_64 emulator — 500-page synthetic graph.

Comparing 2c38dcd4 (this PR) vs dc94048f (baseline)
Device: API 30 x86_64 emulator — 530 pages loaded

Graph Load

Metric	This PR	Baseline	Delta
Phase 1 TTI ↓	30ms	35ms	-5ms (-14%) ✅
Phase 3 index ↓	3129ms	3572ms	-443ms (-12%) ✅

Interactive Write Latency (during Phase 3)

Metric	This PR	Baseline	Delta
Write p95 (baseline) ↓	9ms	8ms	+1ms (+13%) ⚠️
Write p95 (during phase 3) ↓	12ms	14ms	-2ms (-14%) ✅
Jank factor ↓	1.33x	1.75x	-0.42x (-24%) ✅
Concurrent writes ↑	15	18	-3ms (-17%) ⚠️

SAF I/O Overhead (ContentProvider vs direct File read)

Measures Binder IPC cost added by ContentResolver per readFile() call.
Real SAF via ExternalStorageProvider will be higher on device; this is a lower bound.

Metric	This PR	Baseline	Delta
Direct read / file ↓	0.0ms	0.0ms	0 (0%)
Provider read / file ↓	0.2ms	0.2ms	0ms (-15%) ✅
IPC overhead ratio ↓	5x	6x	-1x (-17%) ✅
↓ lower is better · ↑ higher is better