fix(review): drop parity-allowlist entries whose divergences are now fixed

The server/browser type-parity gate (#3979) shipped an allowlist naming
four divergences as in-flight, two of them by their own text: "open PR
#3973" and "open PR #3971". Both merged, so the entries mute nothing and
the gate correctly refuses them:

  [spatialTypes:IFCSPATIALZONE]        the type is now handled by BOTH
  [spatialTypes:IFCMARINEPART]         sides -- the divergence this entry
  [spatialTypes:IFCFACILITYPARTCOMMON] mutes is gone
  [properties:IFCCOMPLEXPROPERTY]

Each PR was green alone; only the merged tree is red, because #3979 added
the gate and #3971/#3973 removed the divergences it was told to expect.

The gate's own regression tests used two of those entries as fixtures for
"an allowlisted divergence does not fail on its own". Repointed at
surviving entries rather than deleted, and split across both statuses the
allowlist can carry: one `pending`, one `deliberate`. That is strictly
more coverage than before, which only exercised `pending`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0193douQ6sTYHE65DJmyAei9

Author: louistrue

scripts/check-server-browser-type-parity.mjs

@@ -184,19 +184,6 @@ export const ALLOWLIST = {
   'relationships:IFCRELASSIGNSTOPRODUCT': { status: 'pending', note: '#3964, tracked with #3969' },
   'relationships:IFCRELREFERENCEDINSPATIALSTRUCTURE': { status: 'pending', note: '#3964, tracked with #3969' },
 
-  // #3965: server never promotes a *contained* (not aggregated) spatial
-  // element into its own hierarchy node. TS treats IfcSpatialZone (the
-  // Revit Family+Dynamo pattern), IfcMarinePart and IfcFacilityPartCommon as
-  // spatial-structure nodes; the server's `is_spatial_type` does not yet.
-  // Open PR #3973 closes #3965.
-  'spatialTypes:IFCSPATIALZONE': { status: 'pending', note: '#3965, open PR #3973' },
-  'spatialTypes:IFCMARINEPART': { status: 'pending', note: '#3965, tracked with #3973' },
-  'spatialTypes:IFCFACILITYPARTCOMMON': { status: 'pending', note: '#3965, tracked with #3973' },
-
-  // #3963: the server has no IFCCOMPLEXPROPERTY arm at all and drops the
-  // whole containing PropertySet; the browser path resolves it via
-  // parsePropertyValueWithComplex. Open PR #3971 closes #3963.
-  'properties:IFCCOMPLEXPROPERTY': { status: 'pending', note: '#3963, open PR #3971' },
 
   // #3254: IfcPhysicalComplexQuantity groups other quantities instead of
   // carrying a measure itself, so neither side resolves it to a Quantity —

scripts/check-server-browser-type-parity.test.mjs

@@ -178,8 +178,13 @@ test('SPATIAL TYPES: RED when a type is removed from the Rust is_spatial_type ar
   assert.match(out, /TS parser .* handles `IFCBUILDINGSTOREY` but the Rust server .* does not/);
 });
 
-test('SPATIAL TYPES: an allowlisted divergence (IfcSpatialZone, #3965/#3973) does not fail on its own', () => {
-  assert.ok(Object.hasOwn(ALLOWLIST, 'spatialTypes:IFCSPATIALZONE'));
+test('ALLOWLIST: a `pending` divergence does not fail on its own', () => {
+  // #3965's spatialTypes entries and #3963's properties entry used to be the
+  // fixtures here; #3973 and #3971 closed those divergences, so the gate's
+  // own stale-entry check demanded their removal. Repointed at a divergence
+  // that is still genuinely open rather than deleting the coverage.
+  assert.ok(Object.hasOwn(ALLOWLIST, 'relationships:IFCRELCONNECTSELEMENTS'));
+  assert.equal(ALLOWLIST['relationships:IFCRELCONNECTSELEMENTS'].status, 'pending');
   const { status, out } = runOn({});
   assert.equal(status, 0, out);
 });
@@ -193,8 +198,12 @@ test('SPATIAL TYPES: removing IfcSite from the TS enum list surfaces as a TS-sid
 
 // -- properties -----------------------------------------------------------
 
-test('PROPERTIES: an allowlisted divergence (IFCCOMPLEXPROPERTY, #3963/#3971) does not fail on its own', () => {
-  assert.ok(Object.hasOwn(ALLOWLIST, 'properties:IFCCOMPLEXPROPERTY'));
+test('ALLOWLIST: a `deliberate` divergence does not fail on its own', () => {
+  // The sibling of the test above, for the other allowlist status: a settled
+  // trade-off rather than an in-flight fix. Together they prove suppression
+  // works for both statuses the allowlist can carry.
+  assert.ok(Object.hasOwn(ALLOWLIST, 'quantities:IFCPHYSICALCOMPLEXQUANTITY'));
+  assert.equal(ALLOWLIST['quantities:IFCPHYSICALCOMPLEXQUANTITY'].status, 'deliberate');
   const { status, out } = runOn({});
   assert.equal(status, 0, out);
 });