analytics(android): Kotlin LiftMetrics twin of the Swift engine (#2099)

[ryanbr]

Lift Log (#2099) shipped its analytics on Swift only. This adds the Kotlin twin,
and two re-review passes over it found work worth doing.

What is here

LiftMetrics.kt mirrors StrandAnalytics.LiftMetrics: volumeLoadKg,
sessionLoad, estimatedOneRepMaxKg, perExercise, rpeProfile,
muscleCounts, plus the ReferenceDose constants.

LiftMuscle.kt carries the 20 muscle tokens in Swift's order and spelling,
compared mechanically rather than by eye. The encoded list crosses a .noopbak
boundary, so a reordering would silently remap stored data on restore.

Two oracle tests follow the CLAUDE.md method: the Swift side was compiled
standalone with swiftc -O and its stdout pasted in verbatim. No expected value
in either test was written by hand.

A parity bug the second re-review found

Swift's LiftSetRow.init normalises a row's secondary list at construction:

self.secondaryMuscles = LiftMuscle.decodeList(
    LiftMuscle.encodeList(secondaryMuscles, excluding: primaryMuscle))

so LiftMetrics never sees a repeated muscle on that side. The Kotlin Row
carried the list through raw, and muscleCounts strips only the primary, never
duplicates. A set naming a muscle twice was counted twice for it. Measured on
both sides, for one working set with primary chest and secondaries
[triceps, triceps, chest]:

	fractional triceps	indirect sets
Swift	0.500000	1
Kotlin, before the fix	1.000000	2

Double fractional credit, compared against reference doses derived under the
fractional method, so the comparison those doses exist for stops holding.

Row now applies the same decode-of-encode at construction, where Swift applies
it, so any later reader sees the list Swift would rather than only muscleCounts
being patched. It is no longer a data class, because the generated copy()
bypasses the constructor and would hand back an unnormalised row.

The first oracle was blind to this by construction. Its Swift stub declared
LiftSetRow as a plain memberwise struct, modelling LiftMetrics in isolation
rather than how it is actually fed, so the first pass mutation-tested the wrong
thing and passed. The stub now carries the real init's normalisation verbatim,
the fixture gains a Dip row naming triceps three times plus the primary, and a
normalisedSecondaries block pins the per-row list itself so a regression names
the cause rather than a stray sum.

The stored-data codec had no test

LiftMuscle.encodeList and decodeList had zero Kotlin coverage, while both
now claim a twin, which made the ledger treat them as guarded when nothing
guarded them. They are the one part of the Lift Log that is a stored-data
contract, so a divergence is silent corruption on restore rather than a wrong
number on a screen.

LiftMuscleParityOracleTest pins them where the two languages genuinely differ:

• Swift's split(separator:) omits empty subsequences; Kotlin's split(",")
  keeps them. "chest,,biceps", ",", "chest," and ",chest" pin that the
  two agree anyway, an empty token resolving to no case on either side. That was
  reasoned to be safe when the twin was written; now it is measured.
• decoding does not deduplicate on either side while encoding does, so
  "chest,chest" pins the asymmetry as deliberate
• tokens match exactly: " chest" is not trimmed, "CHEST" is not case-folded

Two smaller findings from the same passes

• Both oracle tests formatted doubles with the default locale, so they would
  fail for anyone running the suite on a comma-decimal machine while passing in
  CI. Pinned to Locale.ROOT.
• perExercise assumes ord is unique. It is, because ord is 0-based within
  a session and the only caller passes one session's sets. Recorded in the
  source because if that changes the platforms disagree on ties: Kotlin's
  sortedBy is stable where Swift's sorted(by:) is not, so Swift would also
  stop agreeing with itself. The fix then is to make ord unique, not to
  imitate an unspecified order.

Verification

• both oracles green under --no-build-cache, result XML mtime checked against
  the clock each time
• mutation-tested, each turning the relevant oracle red: dropping Row's
  normalisation, adding .distinct() to decodeList, removing the primary
  exclusion in encodeList, and inverting the maxWithOrNull comparator
• the Swift side of this diff is 12 /// lines and zero code lines

Ledger effect, measured

Measured by running the ledger on a clean worktree and on this branch at the
same base, then set-diffing requirement identities rather than comparing totals
between runs. Re-measured at branch HEAD after the Row change, not carried
over from the first commit:

kind	main	this branch
add-unpaired-function	32	27
add-unpaired-constant	24	19
add-unpaired-file	3	2
add-unpaired-property	2	2
add-finding	1	5
total	62	55

Twelve Swift-side requirements retire: six functions, five constants, and the
file entry, which follows from the function pairs. Five arrive: fromRaw,
Kotlin-only by design because Swift gets the equivalent from
RawRepresentable.init(rawValue:), and four test-only-callsite findings.

Twin claims are directional, which is the part that is easy to miss. Claims
written only in the Kotlin files retired Kotlin-side entries and left all twelve
Swift-side entries standing; the reciprocal claims in LiftMetrics.swift are
what retired those. The same asymmetry CLAUDE.md notes for oracles.

The five that arrive fold into the #2229 authority decision rather than being
declarable here.

What this does not do

Android has LiftEntities.kt and LiftingImporter.kt but no Lift Log screen,
so nothing in the app calls this engine yet. volumeLoadKg and
estimatedOneRepMaxKg avoid the test-only-callsite finding only because
perExercise calls them internally, which is a fact about the call graph rather
than evidence they are wired up. The engine is deliberately ported ahead of its
consumer, and this does not make the board green.