Fail when the mirror is more permissive than the system it mirrors

[sumerjohal]

Fail when the mirror is more permissive than the system it mirrors

hub.users.phone was relaxed to nullable and non-unique in migration/models.py,
and phone was removed from the constraint guard, while ar2-hub still enforced
NOT NULL UNIQUE on that column. The import consequently reported 0 rejected
accounts where a real run against the hub would still have rejected 85 -- 8 with
no phone, 77 sharing a number. The constraint was removed from the simulation,
not from the system.

That is the worse failure shape available: not an error, but a clean bill of
health for an import that cannot happen. The existing drift guard compared
column names only, so it passed throughout -- the column was still called
phone.

• test_mirrored_constraints_match_the_real_schema compares nullability and
  uniqueness against the real models, and fails only on permissiveness. A
  mirror that is stricter than reality predicts rejections that will not
  happen, which is a false alarm; a mirror that is looser predicts acceptance
  for rows the system rejects, which reads as success.

• The docstring on test_hub_constraints_the_import_depends_on_are_still_there
  records why phone legitimately left both lists, and that the order it
  happened in was backwards. Relaxing the guard is the last step, never the
  first.

• The real relaxation is ar2-hub#7, with the DDL create_all will not apply.

Also, three reporting defects. Every number below is one a reader would act on,
and each was wrong in the direction of looking worse or looking better than the
run actually was.

• 268 fields that resolved correctly on an identical content hash were counted
  as quarantined and then listed under DECISIONS REQUIRED. Every one had
  aliased to its canonical row and still resolves. A run that rejected 7 fields
  read as a run with 275 open problems. They now count as resolutions, split
  into exact-geometry and above-threshold matches, because certainty and
  judgement should not share a number.

• Every imported point was counted as canonicalization-altered geometry,
  taking that figure from 3,597 to 18,184 and converting a real signal about
  boundary repair into a headcount of pins. A point has no boundary to repair.

• The point count was not reported at all, though a registry that is half pins
  is a different thing to plan around than one that is all boundaries. It was
  the most consequential fact about the run and appeared nowhere in it.

• "quarantined" is now "REJECTED, not imported", with the share of the total,
  and the decisions section says that a reason naming a geometry type is
  usually a missing code path rather than a policy question.

Finally, the harness submodule moves to f7ac8b0. The pinned revision counted
ruff's "All checks passed!" banner as one violation, so CI reported 1 where this
tree has 36 -- the ratchet has been reading green while blind. The gating
workflow also installs ruff unpinned, which the earlier pin missed because it
only covered ci.yml; patches/pin-ruff-in-stomata-workflow.patch has that, since
my token cannot write .github/workflows.