fix(usage): let a withdrawal win against an activation that is still starting

The last open item from the #1304 review.

/disable overlapping an in-flight /enable was silently lost. While
activation generates its identity and writes its binding file the row
still reads `disabled`, so disable()'s conditional update matched no
rows, and the lease conflict raised by its tick() was swallowed as
expected noise. The admin was told participation was off; the activation
then completed and left it on. An opt-out that does nothing is the one
failure this feature cannot have.

disable() now records cancel_requested first and unconditionally —
before the case-by-case work — and enable() claims its state with a
single conditional UPDATE that tests the flag alongside the status.
Re-reading the flag and then updating would only have moved the window;
making the claim itself carry the condition closes it, so whichever of
the two lands first wins outright and the loser writes nothing.

Nothing is registered when the claim fails, so there is also nothing to
delete remotely — the cancelled activation leaves no identity behind.
The flag is cleared at the start of enable(), so a cancellation from an
earlier participation cannot veto a later deliberate opt-in.

The column is migration 202 rather than an edit to 201. 201 already
shipped on this branch and knex records it as applied, so folding the
column in would have skipped every database that had already run it and
the first /disable would have failed on a missing column. Verified both
ways: a fresh install gets the column from 201+202, and a database
migrated before 202 existed gains it when 202 arrives.

Three tests. With the condition dropped from the claim, the race case
fails and the other two pass.

Refs #1110

backend/src/usage/UsageService.js

@@ -220,29 +220,63 @@ class UsageService {
           'Finish the current participation before rejoining'
         );
       this.collectorUrl();
+      // A cancellation left over from an earlier participation must not veto
+      // this deliberate opt-in, so the flag is cleared before the slow work
+      // starts. Anything set from here on is a withdrawal aimed at THIS
+      // activation.
+      await this.db('product_usage_state')
+        .where({ id: 1 })
+        .update({ cancel_requested: formatBoolean(false) });
+
       const identity = generateIdentity();
       const pending = makePacket(identity, 'register', 0, {
         consent_version: consent
       });
-      await this.db('product_usage_state')
-        .where({ id: 1 })
+      // Identity generation and the binding file are the slow part, and the
+      // row still reads `disabled` throughout — which is why /disable could
+      // not see an activation in flight and its conditional update matched
+      // nothing.
+      const instanceBinding = await this.binding(true);
+
+      // The claim itself carries the check. Re-reading the flag and then
+      // updating would only move the window rather than close it: this is one
+      // conditional UPDATE, so a /disable that lands first makes it match no
+      // rows and the registration is never sent.
+      const claimed = await this.db('product_usage_state')
+        .where({ id: 1, status: 'disabled' })
+        .whereNot({ cancel_requested: formatBoolean(true) })
         .update({
           status: 'activation_pending',
           notice_dismissed: formatBoolean(true),
           installation_id: identity.installation_id,
           public_key: identity.public_key,
           private_key_encrypted: this.encrypt(identity.private_key),
-          instance_binding: await this.binding(true),
+          instance_binding: instanceBinding,
           sequence: 0,
           pending_packet: JSON.stringify(pending),
           last_error: null
         });
+      // Withdrawn while activating. Participation stays off and nothing was
+      // registered, so there is nothing to delete remotely either.
+      if (!claimed) return;
+
       await this.deliver(await this.state());
     });
     return this.status();
   }
 
   async disable() {
+    // Recorded unconditionally and first, because the interesting case is the
+    // one where there is seemingly nothing to stop: while /enable is still
+    // generating an identity the row reads `disabled`, so the conditional
+    // update below matches nothing and the lease conflict from tick() is
+    // swallowed — the admin was told participation was off while the
+    // activation went on to complete. enable() claims its state conditionally
+    // on this flag, so a withdrawal that lands during that window wins.
+    await this.db('product_usage_state')
+      .where({ id: 1 })
+      .update({ cancel_requested: formatBoolean(true) });
+
     // Stop collection before waiting for an in-flight send. The sender checks
     // state again before delivery and preserves this stop after its response.
     await this.db('product_usage_state')