[Ticket]: No optimistic-locking path is exercised

## Type

Spike / Investigation

## Summary

We need to exercise the optimistic-locking path because the proxy already forwards `If-Match` and
relays `etag`, and the data provider supports `@version`, but the console performs zero update
operations today, so this path has never actually been proven to work.

Expected result:
> Once an edit path exists in the console (tracked in Epic 4), a `412` conflict from a real or
> simulated concurrent edit is handled correctly and covered by a test.

## Intent

Optimistic-locking plumbing (`If-Match` forwarding, `etag` relay, `@version` support) was built
ahead of any feature that would use it. Unexercised infrastructure is a latent risk: it could be
subtly broken and nobody would know until the first real edit ships. This ticket exists to make sure
that first edit doesn't also become the first (production) test of the locking path.

## Source of truth (links)

- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/apps/console/src/server/proxy-target.ts#L62-L71
- https://github.com/ADORSYS-GIS/converse-frontends/issues/284

## Current Behavior

`apps/console/src/server/proxy-target.ts:62-71` defines `FORWARDED_REQUEST_HEADERS` (including
`if-match`) and `FORWARDED_RESPONSE_HEADERS` (including `etag`), and the refine data provider
supports `@version`-based optimistic locking. The console performs zero update/mutation operations
against a versioned resource today, so this path — request `If-Match`, response `etag`, and a `412`
conflict on mismatch — has never been exercised or tested.

## Expected Behavior

Once an edit path exists in the console (the first candidate is likely the project-creation or a
project-update flow from Epic 4), a concurrent-edit scenario producing a `412` is handled: the UI
surfaces a clear conflict message (not a generic error), and the handling is covered by a test that
simulates the `412` response.

## Acceptance Criteria

- [ ] Given an edit path exists (post-Epic 4), when a `412` response is returned by the backend due
to a stale `If-Match`/`etag`, then the console surfaces a clear, specific conflict message —
not the generic `ErrorLine` retry treatment used for unrelated failures.
- [ ] Given the same scenario, when the user retries after refreshing, then the edit succeeds with
the current `etag`.
- [ ] Error cases are handled safely — a `412` does not crash the screen or silently discard the
user's edit.
- [ ] Existing behavior is not broken for any read-only flow that already relies on `etag`/`If-Match`
forwarding incidentally.
- [ ] Relevant tests are added or updated — at minimum a test simulating a `412` response and
asserting the UI's conflict-handling behavior.
- [ ] Verification evidence is provided.

## Out of Scope

- Building the edit path itself (tracked in Epic 4 — this ticket is a dependent follow-on, not a
duplicate of that work).
- Backend changes to the `If-Match`/`etag`/`412` contract.

## Technical Context

Relevant files: `apps/console/src/server/proxy-target.ts:62-71` (header forwarding), the refine data
provider's `@version` handling (wherever it lives in `apps/console/src/client/`), and whichever
Epic 4 edit-path ticket lands first (project creation is the most likely first mutation).

## Risks

Risk: this ticket stays blocked/stale until an edit path exists, and could be forgotten. Mitigation:
it stays in Todo explicitly per its own AC, referenced from the first Epic 4 edit-path ticket's PR
description so it surfaces again when relevant.

## Test Plan

A test (unit or integration) that mocks a `412` response from the proxy for an update mutation and
asserts the console's conflict-handling UI/behavior. Manual verification once real backend
concurrency can be simulated (two sessions editing the same resource).

## Verification evidence

To be filled in by the implementing engineer at PR time, once unblocked by an Epic 4 edit path: test
output and manual verification of the conflict scenario.

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Ticket decomposition

## Human verification completed

- [ ] I understood the intent
- [ ] I checked the source of truth
- [ ] I reviewed all AI-generated text/code
- [ ] I verified the implementation manually
- [ ] I verified the tests
- [ ] I checked for hallucinated assumptions
- [ ] I documented remaining risks
- [ ] I am the accountable owner and accept responsibility for this ticket.