fix(ontology): check read_project for Project on per-ability clients [skip ci]

What does this MR do and why?

Project nodes used read_code as a workaround for #570. A project with its repository turned off was then hidden from users who can see it in GitLab. Project now has preferred_ability: read_project, which Orbit checks for Rails clients that answer each ability. ability stays read_code for other clients and for older webservers. The schema goes to v104 with scope: none, so nothing reindexes.

Related Issues

Closes #570. Relates to #1378. Stacked on !2794 (closed).

Testing

GDK on gitlab-work-vm-2, Reporter user, project 324 with the repository off. Each query made one redaction request.

Query	main	Workhorse with this MR	Rails QueryRunner with this MR
Project 324	0 rows	0 rows	1 row
Project 324 and its branch	0 rows	0 rows	0 rows
Project 323 and its branch	1 row	1 row	1 row

New YAML scenarios in scenarios/security/ pass on ClickHouse.

Performance Analysis

• This merge request does not introduce any performance regression. If a performance regression is expected, explain why.

Queries still make one redaction request. The v103 to v104 clone took 50 seconds on VM-2, and the row counts I checked match.

Agent context: long-form analysis, file-by-file walkthroughs, profiler output, alternatives considered

Deploy order

This MR can ship with !2794 (closed) or later. An older webserver that reads the v104 ontology reads only ability, which is still read_code. On VM-2, main served v104 through Workhorse and through Rails with today's results.

Changes

• config/ontology/nodes/core/project.yaml: preferred_ability: read_project, workaround comment removed.
• Schema 104, scope: none: only resource_checks and is_authorized read the abilities, so every indexed row stays byte-identical.
• Scenarios with by_ability: Project visible with read_project only, Branch hidden without read_code, Branch visible with both. Without by_ability: Project hidden without read_code, as today.