Establish the (laptop_id, tab_id, tab_seq) idempotency key end-to-end so
  saver can recognise a redelivered or re-fired write and dedup it. This is
  the bridge step before the spooler: landing the key now soaks the browser
  stamping in production and de-risks saver's contract change ahead of the
  durable, ordered forwarding the spooler will add.

  The browser owns tab_seq: a monotonic per-tab counter (cd.kata.nextTabSeq)
  incremented once per event-write POST - one value per browser action, even
  when a [test] commits two saver events. All four write paths stamp it (the
  ITE helper, run_tests, auto_revert, checkout). web forwards it through
  app.rb into saver_service's nine write methods as a required argument.

  Tests pass a required tab_seq too: a monotonic next_tab_seq helper gives a
  distinct value per write, since saver only dedups on a truthy tab_seq and a
  constant would collapse two same-laptop/same-colour writes. Adds a
  forwarding test mirroring the laptop_id one.