Measure the time between two events by long-pressing them

"How long after eating did he poo?" is answerable from the log, but only by
reading two times off the screen and subtracting them — and the pair is often
on different days, so it is rarely on screen together at all. Hold one row,
hold another, and a bar along the bottom does the subtraction and keeps it
until you clear it, which is what lets you change day between the two picks.

Any row that is a single moment can be picked: history, notes, weigh-ins. Sleep
and walk rows cannot, being spans — measuring from one would need a rule about
which end, and a rule you have to remember is worse than the feature.

The picks are a module-level variable rather than storage. A measurement is a
question you are asking now, not a setting; but module-level is also what
carries it through the re-render a background sync causes every minute, which
would otherwise wipe a half-made measurement. Ids that stop resolving — deleted
here, tombstoned by another device — leave the pick on the next render instead
of lingering as half a pair.

Two additions beyond what was asked. Holding a picked row unpicks it: that is
not a third selection but an undo of one, and without it a mis-press costs a
clear. And the reading is ordered by time rather than by which was pressed
first, so it is always chronological and never negative — pressing upward
through a log is the natural way to read it.

The press mechanics are all load-bearing: a finger that travels is a scroll and
cancels, a fired press swallows the click that would otherwise also open the
edit dialog, and the platform's own long-press menu is suppressed. That last
part needs user-select: none on the rows, which costs the ability to select a
note's text to copy. Worth stating plainly — it is a real loss, taken because
holding a row now means something else.

checks/extract.mjs gained getters for mutable bindings while writing the checks
for this. It only ever returned a let's value at load time, so measurePick went
stale the moment the code reassigned it and the checks were quietly asserting
against a snapshot. Any future check reading a mutable binding would have hit
the same thing.

checks/extract.mjs

@@ -78,8 +78,10 @@ function declaration(src, masked, name) {
  * load({ names, lets, stubs }) → { ...declarations, set: { <let>: fn } }
  *
  * names  declarations to pull across, in dependency order
- * lets   of those, the mutable ones a check needs to assign (a setter is
- *        generated for each, since a check can't reach the binding otherwise)
+ * lets   of those, the mutable ones a check needs to reach. Each gets a setter
+ *        and a getter: the plain export is the value at load time, so a binding
+ *        the code reassigns (rather than mutates) would go stale and a check
+ *        would quietly assert against a snapshot.
  * stubs  names the extracted code calls but which are not worth extracting —
  *        DOM lookups, chartDays(), and so on
  */
@@ -90,9 +92,10 @@ export function load({ names, lets = [], stubs = {} }) {
   const stubNames = Object.keys(stubs);
   const exported = names.map(n => n.replace(/^.*\s/, ""));
   const setters = lets.map(n => `${n}: (v) => { ${n} = v; }`).join(", ");
+  const getters = lets.map(n => `${n}: () => ${n}`).join(", ");
   const factory = new Function(...stubNames, `
 ${body}
-return { ${exported.join(", ")}, set: { ${setters} } };
+return { ${exported.join(", ")}, set: { ${setters} }, get: { ${getters} } };
 `);
   return factory(...stubNames.map(n => stubs[n]));
 }