Improve start performance

[Felixre7]

Large workout histories make startup take longer and longer. When there are 10s of thousands of records to load this can take in excess of 12 seconds on start which makes the user feel like something is wrong. This change loads as little data as possible at startup, queries other data on demand, and prepares all-time statistics in the background while the user navigates elsewhere, without loading all remaining history into the global store. This gives the majority of the improvement so users with small histories will be unlikely to be able to tell. There were a few other unrelated performance improvements but they were small improvements.

Honestly this is pretty invasive and only effects a tiny handful of people (just me?) so might not be worth it for the main repo. We added an indexed table and searchable columns to speed up history and progression queries, while keeping the original JSON payloads. A more complete solution would break more of that JSON data into directly searchable database fields, so we can query exactly what we need without loading and parsing whole workouts. That is a larger database change and would need to handle older backups carefully.

1. Add SQLite history projections, incremental backfill, serialized writes, and paged history/progression queries while retaining JSON payloads as authoritative data.
2. Coalesce upcoming-workout requests and preserve live edits when merging stored history.
3. Start statistics preparation after a three-second grace period, yield to native idle deadlines, pause offscreen, and share the in-flight result with foreground requests. Cache one result and invalidate it when completed history, units, or the date changes.
4. Reduce repeated model and statistics calculations.
5. Remove the temporary startup markers, render profilers, query timings, and scheduling counters. Local test-package overrides, APKs, and editor settings are excluded.

Review notes: the statistics job runs cooperatively on the JavaScript thread; individual model operations or sorts can exceed the slice budget. Review the database migrations and cache invalidation paths closely.

[github-actions]

Thanks for opening a PR!

A few things that help this get reviewed:

• Describe your changes clearly in the PR description, in your own words. AI-generated summaries tend to be more verbose than necessary and frustrating to read.
• Read the AI Usage Policy.
• Attach screenshots of any visual changes.
• Make sure this PR follows an issue/feature request that's already been accepted as wanted (see Contributing).

PRs that clearly don't follow these likely won't get reviewed in a reasonable timeframe.