Cloud-readiness: session writes need transactions or optimistic concurrency

## Problem

Session playback state is updated with a read-modify-write against Firestore with no transaction and no version check.

- `apps/rpg-maestro/src/app/sessions/sessions.service.ts` — `upsertCurrentTrack` / `upsertShortEffectTrack` read, mutate, then write

Running a single instance made this safe by accident. With two instances — or a single maestro driving the session from two devices — concurrent track changes can clobber each other, and the last writer wins with no detection.

## Proposed rework

- Wrap the read-modify-write in a Firestore transaction, or
- Add optimistic concurrency: a `version` field on the session, written with a conditional update, retried on conflict

Either way the API should be able to tell the caller that its change lost a race, instead of silently dropping it.

The issue points to `apps/rpg-maestro/src/app/sessions/sessions.service.ts` and the `upsertCurrentTrack` and `upsertShortEffectTrack` methods. Start by examining how these methods read, mutate, and write session state to Firestore. Research Firestore transactions or optimistic concurrency using a `version` field. The goal is to wrap the updates to prevent race conditions and return a conflict error to the caller.

Written by the indexing model from the issue text.