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/migrations/core/202_product_usage_cancel_requested.js

@@ -0,0 +1,22 @@
+// Separate from 201 deliberately. 201 already shipped on this branch, and
+// knex records it as applied — so folding the column into it would silently
+// skip every database that had already run it, and the first /disable would
+// fail on a missing column. Its own migration runs everywhere.
+exports.up = async function (knex) {
+  if (!(await knex.schema.hasTable('product_usage_state'))) return;
+  if (await knex.schema.hasColumn('product_usage_state', 'cancel_requested')) return;
+  await knex.schema.alterTable('product_usage_state', (t) => {
+    // Set by /disable so an activation still generating its identity — during
+    // which the row still reads `disabled` — cannot go on to complete after
+    // the admin has asked to withdraw.
+    t.boolean('cancel_requested').notNullable().defaultTo(false);
+  });
+};
+
+exports.down = async function (knex) {
+  if (!(await knex.schema.hasTable('product_usage_state'))) return;
+  if (!(await knex.schema.hasColumn('product_usage_state', 'cancel_requested'))) return;
+  await knex.schema.alterTable('product_usage_state', (t) => {
+    t.dropColumn('cancel_requested');
+  });
+};