Authorize and perform a repository mount

### Task Summary

**Authorize and perform a repository mount** — the second step of #6606, on the infrastructure merged in #6862 / #6866.

Give the platform an endpoint that mounts a versioned LakeFS repository into a computing unit. There is no user-facing mount action: mounting is implied by a Python UDF parameter that names a model or dataset (#6895), so this step is the authorization and execution that step calls into.

The node mounter admits exactly one caller, verified with `TokenReview` against a token bound to the `texera-mounter` audience, and only access-control-service holds one. It is also the right place, since it already decides whether a user may act on a computing unit.

The mounter authorizes nothing — it performs what it is told — so every decision has to be made in that endpoint, before the mounter is asked:

- the request has a shape a mount path can be built from, each component a single safe segment;
- the caller holds write access to the computing unit, mounting being a change to it, so a read-only sharee may use the unit but not alter what it can see;
- the caller may read the repository, matched by name across datasets and models and refused unless exactly one matches;
- the commit belongs to that repository, so an unrelated digest cannot be mounted.

It then resolves which node the unit's pod is on — itself, rather than accepting one from the caller, or anything that can reach it could aim requests at any node's privileged mounter — and forwards.

file-service continues to re-check read access on every byte it serves through its proxy, but as the last line rather than the only one. The read and ownership rules move to a module both services share, so they decide from one definition.

Mounts are released when the computing unit's pod is deleted, by the mounter's pod watcher, so there is no unmount path. Everything stays behind `mounter.enabled`, off by default, as in #6862.

Resolving a logical dataset or model path to the repository and commit backing it, and the engine-side client that calls this endpoint, belong to #6895 — that is where they are used.

### Task Type
- [x] Other (feature implementation — platform)