Lazy-load Settings and Tweaks

[elkimek]

Summary

• defer the Settings and Tweaks module graph behind a cached, retryable lazy loader
• route shell, onboarding, profile-share, and test entry points through the lazy boundary
• keep startup accent initialization in the theme module and let Light import the existing privacy leaf directly
• add loader regression coverage, document the boundary, regenerate the module map, precache the loader, and bump the app version
• ratchet the committed cold-load budget to the newly measured baseline

Why

Settings was part of the returning-user startup graph even when the user never opened it. Moving that feature behind an explicit runtime boundary reduces initial browser work while preserving all existing Settings and Tweaks behavior.

Impact

Compared with the prior merged baseline, a cold mobile load drops from 455 to 450 requests, from 1,953,718 to 1,915,305 compressed bytes, and from 6,075,152 to 5,918,162 decoded bytes. That saves 5 requests, 38,413 compressed bytes, and 156,990 decoded bytes.

Across the broader code-quality audit baseline, the cumulative improvement is 24 requests, 101,905 compressed bytes, and 334,124 decoded bytes.

Validation

• architecture check: 465 modules, 0 cycles
• quality checks: 11/11; largest-file baseline remains 23
• cold-load benchmark: exact 450 requests / 1,915,305 compressed / 5,918,162 decoded, repeated and budgeted
• Settings loader and Settings/Tweaks targeted browser coverage: green
• static, Vitest, origin, Chromium, two-device sync, and responsive suites completed; 384/386 Chromium tests passed in the heavily parallel run, while 2 unrelated import-benchmark clicks were blocked by a concurrently opened guided-tour overlay
• isolated import-benchmarks rerun: 17/17 passed
• Firefox smoke: 3/3 passed