feat: add status and payment capability contracts

docs/MODULE_ARCHITECTURE.md

@@ -213,8 +213,23 @@ Other stable runtime capabilities currently include:
   `calendar.externalProfiles`
 - `poll.scheduling`
 - `notifications.dispatch`
+- `application_status.projection`
+- `payments.requests`
 - `workflow.definitionContributions` and `workflow.runtimeWorker`
 
+`application_status.projection` lets a presentation module resolve the tenant
+and display or request access to an owner-supplied, deliberately bounded
+applicant-status view. The provider retains policy, authorization, token, and
+record ownership; consumers must not query provider tables or enlarge the
+projection.
+
+`payments.requests` carries replay-safe payment obligations and evidence-bound
+manual reconciliation across module boundaries. Procedure modules identify the
+source Case or Workflow in the command and retain the returned payment ID;
+Payments remains authoritative for amount, currency, state, transaction
+reference, and reconciliation evidence. Ledger, invoice, and external payment
+providers remain separate follow-on contracts.
+
 The provider-neutral `idm.relationships` contract carries tenant-scoped typed
 groups, effective-dated identity relationships, and explicit membership
 decisions. It deliberately does not expose IDM persistence models or imply an
@@ -305,6 +320,8 @@ contract checks, are:
 - `files.access`, `files.campaign_attachments`
 - `mail.campaign_delivery`
 - `notifications.dispatch`
+- `application_status.projection`
+- `payments.requests`
 - `poll.availability_matrix`, `poll.option_selection`,
   `poll.response_collection`, `poll.signed_participation`,
   `poll.workflow_context`