[ryanbr]

Rebase of #2493 by @paradix86 onto current main, so the work can land with CI green. The original description there stays the authoritative account of the feature.

Both commits keep @paradix86 as author. Rebase-merge rather than squash so that stays true.

What the rebase changed

One file conflicted, Tools/parity_twin_map.json, which is generated. I took main's copy and regenerated it from source with parity_ledger.py --refresh-derived rather than hand-merging the hunks. The resulting delta is authority counts only: files 507 to 508, functions 4518 to 4520, matching ProfileWeightSync.kt plus its newest and captionDate. A useful side-confirmation from those counts is that only one file registered rather than two, so com.noop.ui sits outside the governed Kotlin roots and HealthConnectWeightSync.kt correctly needs no disposition. That regeneration is folded into the existing parity commit, since that commit exists for exactly this metadata.

No source file was touched by the rebase. The footprint is identical to #2493: 22 files, +423/-19.

Verification

Android unit tests on the rebased tree with --no-build-cache --rerun-tasks, and syncRoomSchemaSnapshot in its own invocation first:

class	tests
ProfileWeightSyncTest	4
HealthConnectWeightSyncTest	5
TodayMetricTilesTest	54
BackupSettingsCodecTest	9
ProfileStoreAgeMigrationTest	9

81 tests, no failures and no errors, with the result XML timestamps checked against the wall clock so these are not a stale read. Every compiler warning in the build predates this branch.

Checked statically as well: all four new string keys are present in the default locale and in all eight translations, and no locale carries a key the default lacks, which is the ExtraTranslation class that only release lint catches. Key counts move 2735 to 2739 in the default and gain four in every locale, so no new drift. The values-de shortfall of one and the values-ru shortfall of 122 both predate this branch.

Separately verified during review: the opt-in genuinely defaults off, the locked stepper blocks taps through clickable(enabled = ...) rather than only dimming via alpha (a dim-only lock would let a manual edit be silently overwritten on the next sync), the imperial branch locks too, and latestWeightKg preserves the previous tie-break so the default-off path is unchanged.

Review notes, non-blocking

• ProfileWeightSync.newest carries a doc comment warning that two readings on the same day resolve only by input order. That cannot happen through the real path: HealthConnectImporter already resolves intra-day by timestamp (if (r.time.epochSecond >= b.weightTs), the same guard its BodyFatRecord and LeanBodyMassRecord neighbours use), and appleDaily holds one row per (deviceId, day). So newest only ever sees one already-latest reading per day. Worth correcting so nobody later threads timestamps through to fix a problem that is not there.
• Turning the toggle on while Health Connect holds no weight yet locks the stepper with nothing to sync. It is disclosed by the caption and the detail string and is reversible, so it stays as built.

Refs #2493