Apply the virtual scope chain to the project entity

Settle every scope operation of the `project` entity on the virtual scope chain. The wiring declares 3 scope operations for it; each one is accounted for below. Resolve ownership through `entity_memberships` joined to `virtual_scopes`; helpers live in `src/ai/backend/manager/models/virtual_scope/queries.py`.

## Convert

- `search_projects_by_domain` — `ProjectRow.domain_name == (SELECT name FROM domains WHERE id = :domain_id)` (`models/project/scopes.py:28`)
- `ProjectFairShareOperationScope` — `ProjectRow.domain_name == :domain_name` (`models/fair_share/scopes.py:69`); catalogued under `project_fair_share` but the predicate scans projects, so it is the same relation

## Already settled

- `search_projects_by_user` — already reads the chain
- `create_project` — the role-managed create path records the domain membership

## Write side

Present. `models/project/creators.py:59` declares `member_of() -> (domain_id,)`.

## Done when

- The two predicates above are one on the chain, not two spellings of the same relation.
- The name-to-id resolution subquery is gone: the virtual scope is keyed on the domain UUID.
- Each converted read has a test proving it returns the same rows as the column-based query on backfilled data.

JIRA Issue: BA-7546

Start with src/ai/backend/manager/models/virtual_scope/queries.py, then inspect models/project/scopes.py:28, models/fair_share/scopes.py:69, and models/project/creators.py:59 to trace the existing chain and membership wiring. Convert the two listed predicates to the domain UUID-based virtual scope and add tests showing identical rows on backfilled data; done means the duplicate column predicates and name-to-id subquery are gone.

Written by the indexing model from the issue text.