admin: serialize service read-modify-publish-persist operations

Nobody has claimed this yet.

## Summary

Admin service CRUD performs a multi-step operation:

1. Read the current service slice from `serviceHolder`.
2. Modify a copy.
3. Publish it through `Proxy.UpdateServices`.
4. Store it back in `serviceHolder`.
5. Persist the individual database change.

The holder protects each get/set, but not the complete transaction. Concurrent authenticated admin calls can read the same generation and publish conflicting replacements.

Persistence failures are currently logged after the in-memory update, which can also leave runtime and restart state different.

## Impact

- Concurrent creates, updates, or deletes can lose each other's changes.
- The proxy and service holder can temporarily end with different snapshots.
- The persisted configuration can diverge from the running configuration.

## Proposed direction

Serialize the complete service mutation, or use generation numbers with compare-and-swap/retry. Define failure semantics for persistence and publication, such as persist-then-publish with rollback, a database transaction plus generation record, or an explicit reconciliation mechanism.

## Acceptance criteria

- Concurrent changes to different services are both preserved.
- Conflicting updates have deterministic last-writer/version-conflict behavior.
- Proxy, holder, and persisted configuration converge to the same generation.
- Failure injection at each stage does not silently report a durable success.

Trace the admin service CRUD operations, serviceHolder access, Proxy.UpdateServices publication, and individual persistence steps described in the issue. First reproduce or inspect concurrent mutations, then define the generation and failure semantics before changing the implementation. Done means concurrent changes are preserved, conflicts are deterministic, and injected failures cannot silently report durable success.

Written by the indexing model from the issue text.