Lazy-load Profile Sharing

[elkimek]

Summary

• add a cached profile-share-loader.js with one real retry and safe shell entry points
• defer the full encrypted Profile Sharing graph until a shell, Settings, client-list, or valid shared-link action needs it
• preserve startup/hash/query shared-link behavior and offline first use
• remove the obsolete Data I/O composition wrapper and update the architecture map, contracts, service-worker shell, and app version
• ratchet the reproducible cold-load reference and ceilings

Why

Profile Sharing was loaded on every returning-user startup even when unused. Keeping only the route-aware loader in the startup graph reduces normal cold-load work without moving encryption, import, validation, or modal responsibilities out of the feature module.

Impact

The repeated cold-load reference moved from 450 requests / 1,915,305 compressed bytes / 5,918,162 decoded bytes to 449 requests / 1,908,488 compressed bytes / 5,890,321 decoded bytes. Profile Sharing still opens from every existing entry point, valid shared links still open automatically, and the full feature remains precached for offline first use.

Validation

• ./run-tests.sh: 486 Vitest tests, 391 Chromium tests, and 472 responsive-theme assertions passed
• targeted Profile Sharing browser coverage: 8/8 passed
• combined coverage: 67.11% functions (67.10% floor); Playwright: 90.92%
• Firefox smoke: 3/3 passed on unchanged rerun
• architecture: 465 modules, 0 cycles
• cold-load benchmark repeated identically at 449 / 1,908,488 / 5,890,321

The coverage pass had the repository's known tour-overlay race in one import-benchmark test (390/391); that unchanged test passed immediately in isolation and the combined coverage ratchet passed. The first Firefox pass likewise hit the known delayed chat-onboarding race before the clean 3/3 rerun.