Introduce cleanup lock reason and system-action flag

Nobody has claimed this yet.

### Willingness to contribute

Yes. The first increment is tracked in draft PR #726.

### Feature Request Proposal

Introduce an optional structured `TIER3_AUTO_CLEANUP` lock reason and an opt-in `SYSTEM_ACTION` request declaration.

### Motivation

Give callers explicit metadata and request signaling for cleanup operations without relying on free-form lock messages or changing existing authorization.

### What component(s) does this feature affect?

- Table Service and generated table client
- Secure client header constants
- Iceberg 1.2 and 1.5 Java catalogs

### Details

Persist optional `reason` in the existing `policies.lockState` and expose it through normal table status retrieval. Add a boolean `system-action` catalog property carried as `X-OpenHouse-System-Action: true|false`; omit the header by default.

Keep this increment limited to these two inputs. Existing lock behavior, authorization, and endpoint signatures remain unchanged. Read/write exceptions, guarded unlock, owner/generation checks, and maintenance-job activation belong in later work.

Start with the Table Service and generated table client, then inspect the secure client header constants and the Iceberg 1.2 and 1.5 Java catalogs. Verify that lock status can expose an optional reason and that the system-action property emits the specified header only when enabled, while existing authorization, lock behavior, and endpoint signatures remain unchanged.

Written by the indexing model from the issue text.