Task: Restore strict tenant scoping on parties

The parties policy scopes to the current tenant alone and the party read uses the default tenant scope, so the root tenant sees only its own parties.

• The parties policy has no system tenant clause and the party model has no shared read scope.
• A database test shows the root tenant lists only its own parties and a tenant only its own.
• The sign-in chooser still shows party names, checked against the running services.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The parties policy admits the current tenant alone and the party read uses the default tenant scope. refdata_party_tenant_isolation_test.sql passes 5 of 5 after the recreate (it failed before, with 771 rows from other tenants). The root tenant's Parties tab lists its own 5 parties. ores.refdata.core.tests pass.