Add discovery guard for flock-scoped EF query filters #613

Context

Follow-up from #388 / PR #611 review. #388 adds combined tenant+flock EF query filters to the 8 current flock-keyed entities. The tests prove every current filter and mutate each conjunct, but the set itself is hand-listed.

A future entity with a FlockId property can receive the mandatory tenant filter while silently omitting flock scoping. Existing tests stay green because they enumerate today's known 8.

This is the flock-axis counterpart to TenantBypassDiscoveryTests: walk the model/source surface, exclude deliberately, never trust a recalled list (AGENTS.md “Writing a guard”).

Required guard

• Discover every mapped entity carrying a scalar FlockId (nullable or non-nullable) and Flock itself.
• Assert it has the flock-scope query-filter conjunct in addition to AccountId tenancy.
• Declare exclusions explicitly with reasons:
  • UserRoleAssignment is the scope source and must not filter itself (circular resolution).
  • Any future exclusion requires a reviewed allow-list entry, not an implicit omission.
• Fail when a new discovered entity is absent from the declared scoped/excluded set.
• Pin a literal floor/count only as a secondary alarm; discovery is authoritative.
• Mutation proof: add a temporary mapped FlockId entity (or remove one filter conjunct) and prove the guard reds; restore and prove green.
• Avoid brittle expression ToString() matching if a structural expression-tree walk is feasible.

Acceptance criteria

• Current 8 scoped entities are discovered automatically.
• UserRoleAssignment is a named, justified exclusion.
• A newly mapped FlockId entity without flock scoping fails the guard.
• A tenant-only filter on an existing flock entity fails the guard.
• Guard does not weaken the existing tenant discovery/bypass guards.