fix: project trust reads fail on concurrent writer lock

## Summary

A concurrent Senpi process can terminate at startup with the raw `Error: Lock file is already being held` while reading an already-persisted project trust decision.

## Deterministic reproduction

1. Use an isolated `SENPI_CODING_AGENT_DIR` with a known `trust.json` decision.
2. Hold `/trust.json.lock` with `proper-lockfile`.
3. Start Senpi in a project containing trust-requiring resources.
4. `ProjectTrustStore.getEntry()` attempts to acquire the writer lock and exits with `ELOCKED` before extensions or the primary turn can run.

## Expected

Readers consume the last atomically published trust snapshot without taking the writer lock. Writers remain serialized, and malformed snapshots continue to fail closed.

## Scope

`packages/coding-agent/src/core/trust-manager.ts` and deterministic regression coverage. No change to trust decisions or project-trust defaults.

Start in packages/coding-agent/src/core/trust-manager.ts and reproduce the concurrent lock scenario using an isolated SENPI_CODING_AGENT_DIR and a held trust.json.lock. Add deterministic regression coverage for reading the persisted snapshot while a writer lock is held; done means readers avoid the writer lock, writers remain serialized, and malformed snapshots still fail closed.

Written by the indexing model from the issue text.