AI Issue: Guard filesystem-backed management operations against read-only mode

Follow-up from #450 (Read-only mode).

## Problem

`isReadOnlyMode()` currently gates RocksDB writes plus analytics/audit writes, but management operations that mutate filesystem state outside the database are not guarded:

- **Component deployments** — `components/operations.js` (writes the components directory).
- **Config updates** — `config/configUtils.js` (writes `harperdb-config.yaml`).
- **Roles/users** — `security/role.js`, `security/user.ts` (system-level identity changes).

A read-only Harper instance can still accept these operations and partially mutate filesystem state, which is inconsistent with the "read-only" contract.

## Proposed change

Add `isReadOnlyMode()` guards at each management entrypoint. Reject with a clear error (HTTP 405) before any filesystem write.

## Benefit

Coherent read-only contract across the database *and* the surrounding application config/assets. Prevents partial state mutations on instances callers expect to be inert.

---

🤖 Identified by Gemini CLI during review of #450; relayed by Claude.

Start by reading the existing isReadOnlyMode() gates and the management entrypoints in components/operations.js, config/configUtils.js, security/role.js, and security/user.ts. Done means each listed operation rejects with HTTP 405 before writing filesystem state, while the existing database, analytics, and audit protections remain intact.

Written by the indexing model from the issue text.