Make project submission idempotent by client request ID

## Problem

A client can lose the response to a successful project/run submission and retry the request. Without a backend idempotency contract, that retry can create a second workload and duplicate accelerator cost. Human-readable names, CLI-local state, and Kubernetes `AlreadyExists` behavior are not sufficient API guarantees.

## Proposed contract

Make project/run creation idempotent using a client-provided request/project ID, scoped to the authenticated tenant and execution namespace:

- Same ID and same submitted-request digest returns the original project/run and never enqueues another workload.
- Same ID and a different submitted-request digest fails with a conflict that identifies the mismatch without exposing another tenant's data.
- A new ID intentionally creates a new execution, even when the submitted bytes are identical.
- Persist the idempotency record atomically before enqueueing so concurrent duplicate requests cannot create duplicate workloads.
- Return whether the response created a run or replayed an existing submission, along with the stable run ID and recorded request digest.
- Make the behavior an API/controller guarantee. The CLI should only supply the ID and display the server response; it must not maintain a local provenance or deduplication ledger.

Hash the exact submitted manifest bytes, or define and version a canonical encoding. Do not use payload digest alone as the idempotency key because identical manifests may be deliberately executed more than once.

## Acceptance criteria

- Retrying after a lost successful response returns the same project/run.
- Concurrent submissions with one ID and identical bytes create exactly one workload.
- Reusing an ID with different bytes returns a deterministic conflict and creates no workload.
- Two different IDs with identical bytes create two intentional executions.
- Status remains retrievable through the stable project/run ID.
- Existing clients remain compatible; capability and schema versioning expose support for the new contract.
- Tests cover request replay, concurrent submission, digest conflict, tenant scoping, and intentional reruns.

## Non-goals

- Deduplicating executions by manifest hash.
- Interpreting project-specific provenance, scientific gates, or application results.
- Conflating submission idempotency with workload retry policy.

Start by locating the API/controller paths for project and run creation, the persistence layer, and the enqueue operation; then inspect how the CLI submits requests. Trace schema and capability versioning and identify the existing status lookup path. Done means the acceptance tests cover replay, concurrency, digest conflicts, tenant scoping, intentional reruns, compatibility, and stable status retrieval.

Written by the indexing model from the issue text.