feat(company-monitoring): expose account-scoped REST/OpenAPI automation

## Parent

#6002

## What to build

Expose the ten Company Monitoring RPCs as the canonical contract for the native UI, customer integrations, and agents, with exact account binding, independent per-handler authorization, bounded snapshots, and latest-state correction/retraction polling.

## Acceptance criteria

- [ ] Accept only a verified Clerk owner or user API key resolving to exactly one active entitled account.
- [ ] Reject legacy scope-less, ownerless static or enterprise, worker, revoked, disabled-root, missing-root, duplicate-root, and wrong-owner credentials.
- [ ] Enforce the explicit six-read/four-write scope matrix in every handler independently of gateway acceptance; read cannot mutate and write-only cannot read.
- [ ] Separate compact list responses from bounded evidence detail and mark all success and error responses no-store.
- [ ] First snapshot returns a signed account/filter/mode/version/expiry-bound boundary, snapshot generation, and poll watermark; later pages preserve that boundary.
- [ ] Snapshot and poll compare cursor generation with the current account root before reading impacts; company removal or generation change returns snapshot_required.
- [ ] Polling returns latest current revisions after the watermark, allowing intermediate coalescence while retaining soft retractions long enough for convergence.
- [ ] Every direct ID and relationship traversal rechecks account and company ownership with uniform not-found behavior.
- [ ] Cursor tampering, expiry, cross-account ID substitution, concurrent snapshot mutation, warm-cache revocation, and forced error paths fail closed without leaking portfolio content.
- [ ] Generated REST/OpenAPI contracts, API typecheck, and gateway integration tests pass with no MCP-specific routes or state.

## Blocked by

- #6005
- #6007
- #6012

Begin by reviewing the blocked dependencies #6005, #6007, and #6012, then trace the existing gateway and Company Monitoring RPC boundaries. Validate the generated REST/OpenAPI contracts, API typecheck, and gateway integration tests against the acceptance criteria. Done means all ten RPCs satisfy the account, authorization, snapshot, polling, ownership, and fail-closed requirements without MCP-specific routes or state.

Written by the indexing model from the issue text.