No integration-tier check for RLS filter collection — rls-isolation needs seeded permission fixtures

## The gap

The RLS filter-collection behaviour fixed in #4358 and extended in #4395 is covered only by unit tests in `packages/MJCore/src/__tests__/entityInfo.rlsFilterCollection.test.ts`. There is no integration-tier check that a user's effective row set actually narrows the way the permission rows say it should.

`rls-isolation.checks.ts` is the natural home.

## Why it was deferred

The check needs **seeded permission fixtures** — an entity with two roles, one bound to an RLS filter and one not, plus a Deny row — and the deterministic integration suite has no fixture for `EntityPermission` / `RowLevelSecurityFilter` rows today. That is the actual work, and it is why this did not ride along with #4358 or #4395.

## What it would pin

The unit tests assert the collection logic in isolation, with hand-built `EntityPermissionInfo` objects. What they cannot catch is a seam:

- a filter collected correctly but never reaching the emitted SQL;
- the permission gate and the RLS reader disagreeing about a user;
- a provider path that builds its own clause and bypasses `GetUserRowLevelSecurityInfo` entirely.

The first two are exactly the kind of thing the deterministic tier exists for.

## Related

- The data-integrity half is tracked separately (the `EntityPermission` server subclass + the nine stale rows).
- #3544 covers a *different* rls-isolation problem (`RLS7`, a suspected unsound client-transport assertion) and is not this.

## Origin

Raised in my review of #4358 and deferred there by agreement; #4395 notes it as out of scope. Filed so it is not lost — it was untracked as of 2026-09-11.

Read packages/MJCore/src/__tests__/entityInfo.rlsFilterCollection.test.ts to understand the existing collection cases, then inspect rls-isolation.checks.ts as the integration entry point. Add deterministic seeded permission fixtures covering two roles, an RLS filter, an unfiltered role, and a Deny row. Done means the integration check verifies that the effective row set narrows according to those permissions.

Written by the indexing model from the issue text.