client SDK: add `approvals` namespace; remove dead `workflow` surface (ADR-0019)

[xuyushun441-sys]

Summary

The @objectstack/client SDK is out of sync with the server REST surface around approvals/workflow:

1. Missing: there is no client.approvals namespace, even though the server exposes the canonical approval-decision API. This is the only path that resumes a suspended flow run (ADR-0019), so without a typed method every consumer hand-rolls fetch, or worse, bypasses it by data.update-ing the request status (which mirrors the status but does not resume the flow).
2. Dead: client.workflow.* and the workflow route/contract are leftovers from the workflow engine that was removed (Workflow Rules removed in refactor(automation): remove Workflow Rules; reclaim workflow for state machines #1398; approval collapsed into Flow in ADR-0019). Nothing implements /api/v1/workflow anywhere in the monorepo — these methods can never succeed.

Found while building the mobile app's approvals UI: client.workflow.approve silently no-ops and there's no typed approvals call, so we had to data.update the status (semantically wrong — the blocked flow run is never resumed).

Evidence

Server HAS the approvals API — packages/rest/src/rest-server.ts registerApprovalsEndpoints() (always mounted; service via ctx.getService('approvals')):

• GET /api/v1/approvals/requests (filters: status, object, recordId, approverId, submitterId)
• GET /api/v1/approvals/requests/:id
• POST /api/v1/approvals/requests/:id/approve -> svc.decide() -> finalizes the request and resumes the owning flow run
• POST /api/v1/approvals/requests/:id/reject
• GET /api/v1/approvals/requests/:id/actions (audit trail)

Client LACKS it — packages/client/src/index.ts: no approvals namespace and no approvals key in the route map (getRoute, ~line 3277).

workflow is dead — no /api/v1/workflow route is registered anywhere; no service-workflow / plugin-workflow package exists. Only leftovers remain:

• packages/client/src/index.ts:2464 — workflow = { getConfig, getState, transition, approve, reject }
• packages/client/src/index.ts:3288 — route map workflow: '/api/v1/workflow'
• packages/spec/src/contracts/workflow-service.ts — IWorkflowService contract (+ Workflow* types), unimplemented/unregistered
• packages/spec/src/system/core-services.zod.ts:42,84 — 'workflow' CoreServiceName (optional), surfaces as workflow: { status: 'unavailable' } in discovery

Per ADR-0019 ("Collapse Approval into Flow"): "Workflow Rules were already removed in #1398, and workflow was reclaimed for state machines." — but no state-machine workflow service was ever shipped, so the surface is dangling.

Proposed changes

Add client.approvals (mirror the existing automation namespace style):

approvals = {
  list:    (filters?) => GET  /api/v1/approvals/requests?…,
  get:     (id)       => GET  /api/v1/approvals/requests/:id,
  approve: (id, { comment?, actorId? }) => POST /api/v1/approvals/requests/:id/approve,
  reject:  (id, { comment?, actorId? }) => POST /api/v1/approvals/requests/:id/reject,
  actions: (id)       => GET  /api/v1/approvals/requests/:id/actions,
}

• add approvals: '/api/v1/approvals' to the route map.

Remove the dead workflow surface:

• delete the workflow namespace + route-map entry in packages/client/src/index.ts
• delete packages/spec/src/contracts/workflow-service.ts (IWorkflowService, Workflow* types) and its test
• drop 'workflow' from CoreServiceName (core-services.zod.ts) and any discovery default that advertises it

Note: object state machines now live as Flow nodes / field-level, so transition/getState/getConfig have no replacement — remove, don't re-point.

Acceptance criteria

• client.approvals.{list,get,approve,reject,actions} exist and hit /api/v1/approvals/requests…
• No workflow references remain in @objectstack/client (namespace + route map)
• IWorkflowService / Workflow* types and the 'workflow' CoreServiceName removed (or explicitly kept with a deprecation note if state-machine work is still planned)
• discovery no longer advertises a workflow service
• spec + client typecheck/test green

Secondary (separate issue?)

reports (/api/v1/reports…, 8 routes) and sharing/sharingRules (/api/v1/sharing/rules…) also have server routes but no client namespace.

---

Filed from the mobile app, which will switch its approvals decision to client.approvals.approve once this lands (currently using a data.update workaround that doesn't resume the flow).