[ryanbr]

Two commits: a PII fix that turned out to be a prerequisite, then the feature.

1. The strap-log header was never redacted

The log body is scrubbed as it is appended — Android via WhoopBleClient.log(), Swift as each line enters the ring. The header is not. It is built from the diagnostics block and appended raw at the four direct-share export sites — Android LogExport (share + scheduled) and Swift LiveState (exportableLogText + scheduledExportText) — which bypass the bundle assembler entirely.

Correction from re-review: an earlier draft of this PR said all bundle paths leaked too, and edited TestBundleAssembler. That was wrong — assemble() already re-scrubs every entry via redactEntries, on both platforms, and that file documents itself as "the single scrub point". The edit is reverted.

LogExport's own comment records the assumption that hid the real gap:

Lines are ALREADY PII-scrubbed by WhoopBleClient.log(), so no extra redaction here.

True of the body it describes; not true of the header beside it.

That header already prints device ids. A single-strap install is my-whoop and harmless — which is why this has gone unnoticed — but a re-added or second strap is whoop-<MAC>. So the funnel's no raw biometric samples under '<id>' line, and the orphan-id line #1620 added, can put a BLE address into a file whose entire purpose is being attached to a public issue.

Every header line now goes through the same redactor as the body. The mask keeps the first and last octet (F1:••:••:••:••:DE), so two straps stay distinguishable without publishing an address.

I found this while building the inventory below, which would have widened the exposure from the active id to every id. Both platforms had it; both are fixed.

2. Name every paired device

The Strap & data header reads the last-connected prefs, not the registry — so it can only ever describe one device. On a two-strap install the log never mentions the second at all, which leaves every id-bearing line uninterpretable: dayOwner readId=… tells you which id a day was read from, and the funnel's orphan check names the id holding a night's samples, but neither means anything without knowing which ids exist, which is active, and which actually synced.

Devices:     2 registered (1 active, 1 paired, 0 archived)
  device id=my-whoop status=ACTIVE brand=WHOOP model=WHOOP 5.0 / MG lastSeen=3h 10m ago
  device id=whoop-B status=paired brand=WHOOP model=WHOOP 4.0 lastSeen=10m ago

Sorted ACTIVE first, then most-recently-seen, then by id — stable, never dependent on registry iteration order. The active row is deliberately not assumed to be the most recently seen: switching straps leaves the old one with the fresher lastSeen, which is precisely the case this exists to make readable, and there is a test for it.

The ACTIVE marker compares against the registry's activeDeviceId rather than trusting the row's own status field. When those disagree — row says active, registry points elsewhere — the line shows it rather than hiding it. That divergence is a corruption a two-strap install can produce, and it should be visible.

Parity

Byte-identical across five cases, diffed rather than eyeballed (Swift formatter extracted, compiled standalone, stdout diffed against the JVM's). relTime already agreed byte-for-byte between the platforms, so the durations match without a second implementation.

One structural asymmetry, recorded deliberately: Android's header block is suspend and reads the registry inline; Swift's strapStateLines() is sync and prefs-only by contract ("SYNC, offline-safe"), so the Swift inventory takes its own store handle inside the async dynamicLines. Same output, same position in the log, different seam — noted so nobody "aligns" them by making strapStateLines() async.

A limitation on Apple, found in re-review

The ids the inventory prints redact differently on the two platforms, because they are minted
differently:

	re-added strap id	after redaction
Android	whoop-<MAC>	whoop-F1:••:••:••:••:DE — two straps stay distinguishable
Apple	whoop-<CoreBluetooth UUID>	whoop-<device> — identical for every strap

redactPii's third rule masks a peripheral UUID wholesale, so on Apple every re-added strap reads
whoop-<device>. The inventory is still useful there — counts, statuses, models and lastSeen all
differ per row — but the id cross-reference is not: dayOwner readId= collapses to the same token,
so a row cannot be tied to the day that read it.

This is pre-existing (it is the redactor's behaviour, not this block's) and the inventory inherits it
rather than causing it. Not fixed here. The obvious remedy is a short stable non-identifying
discriminator beside the id — an FNV-1a of the id, per the cross-platform hashing rule, which survives
redaction because it is not the identifier — and that deserves its own change rather than being folded
into this one.

Verification

• compileFullDebugKotlin clean; full com.noop.testcentre suite (131 tests) green.
• 5 JVM tests for the inventory + 3 for the redaction, each with a twinned StrandTests file.
• Redaction tests pin the property (no raw MAC survives a header line) rather than the call sites, since a refactor may legitimately move those — covering the device-id line, the diagnostics: check other device ids before blaming a fresh re-add #1620 orphan line, and an address-free id that must pass through untouched.
• doc_comment_lint and i18n_audit --ci main clean.
• Needs app-build: the Swift edits are app-target.