ADR-004: back out of on-stack RAP; retarget to starter customizing tenant

Both tenants belong to the same starter system: my429480 is its
customizing tenant (client 100, key-user extensibility only, no ABAP)
and my431353 is its development tenant (client 080). This package had
recorded my429480 as "productive" and ADR-002 had assumed it offered
developer extensibility; both were wrong.

- ADR-004 withdraws the on-stack RAP route and moves the application to
  a side-by-side runtime against released OData APIs. ADR-002 marked
  superseded.
- Development tenant my431353 parked: all 19 ZARENA_PLM objects left
  active, sources kept in docs/handover/rap/ as reference, so the route
  stays reversible.
- Replacement host left open as OQ-11 (key-user extensibility vs CAP
  side-by-side); recommendation recorded as CAP. No build starts until
  OQ-11 is closed.
- RAP-dependent items V-2, V-3, OQ-5, OQ-8, OQ-9, OQ-10 parked rather
  than closed.
- Tenant references corrected across CLAUDE.md, KNOWLEDGE.md,
  app/README.md, the RAP handover README, the rap-developer agent and
  the reentrance-login helper README.

No SAP tenant was modified.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/adr/ADR-004-back-out-of-on-stack-rap.md

@@ -0,0 +1,80 @@
+# ADR-004 — Back out of on-stack RAP: side-by-side against released APIs
+
+Date: 2026-09-29 · Status: Accepted (supersedes ADR-002; partly revives ADR-001)
+
+## Context
+
+ADR-002 moved this package on-stack: a RAP approval business object and a Fiori
+Elements app inside the tenant, with side-by-side reduced to a connectivity
+worker, and CAP written out of the architecture. I built that. On the starter
+system's development tenant `my431353` (client 080) the approval business
+object is complete and active — 19 objects in `ZARENA_PLM`, ATC clean, the UI
+service published on 2026-09-16 — and the Fiori Elements app in `app/` is built
+against a mock of it.
+
+Two facts have since changed the ground under that decision.
+
+**The tenant I work in cannot host it.** `my429480` and `my431353` are two
+tenants of the same starter system: `my429480` is its **customizing** tenant
+(client 100) and `my431353` is its **development** tenant (client 080). The
+customizing tenant supports **key-user extensibility only** — no ABAP, no RAP;
+developer extensibility exists only on client 080 [source: fiori-tools-samples
+`misc/s4hana/README`, "Tenant Types", verified 2026-09-29]. ADR-002 was written
+believing `my429480` offered developer extensibility, and this package
+compounded the error by recording `my429480` as "productive". Both readings
+were wrong.
+
+**I am not carrying the ABAP build.** The RAP route costs more than this
+package can justify: every source has to be pasted into an editor by hand,
+because no agent-side ABAP authoring path exists (V-4, answered 2026-09-15: no;
+SAP's editing tool is planned for Public Edition 2702), and the one workaround
+I tried — reentrance-ticket login for a community ADT server — was built,
+tested and rejected on evidence (2026-09-18). Outside advice is that no ABAP is
+needed for this integration. Nothing I built on-stack ever reached a business
+user: ARN-007 (IAM app, business catalog, business role) was never started, and
+the business object still runs `authorization master ( none )`.
+
+## Decision
+
+I withdraw the on-stack RAP route. The application moves back out to a
+side-by-side runtime consuming released OData APIs, with the customizing tenant
+`my429480` (client 100) as the sync target and configuration home.
+
+I **park** the development tenant `my431353` rather than clean it: all 19
+objects stay active in `ZARENA_PLM`, and their sources stay in
+`docs/handover/rap/`. Parking costs nothing — the package carries no transport
+recording and the tenant is non-productive — and it keeps the route reversible
+if the constraint or the advice changes.
+
+I do **not** decide the replacement host here. That is OQ-11: key-user
+extensibility in the customizing tenant (custom business object plus a low-code
+UI) versus a CAP service side-by-side on BTP. My recommendation is CAP, because
+the connectivity worker has to live side-by-side whatever else happens, and one
+runtime beats two. No build starts until OQ-11 is closed.
+
+## Consequences
+
+Kept, unchanged in value:
+- the connectivity worker (`worker/`) — built, 137 tests green, never deployed;
+  it is the only encoding of the Arena session, delta-cursor and webhook logic
+  outside the Express predecessor, and it is needed under either OQ-11 option;
+- the Fiori Elements app (`app/`) — repointable, because 35 of its 58
+  annotations are already local rather than backend-owned (OQ-10);
+- the RAP sources and the live objects, as reference and as a reversible route.
+
+Withdrawn or weakened:
+- the acceptance test's "finds its data in the Custom CDS Views app" clause —
+  unreachable from client 100; what survives is launchpad reachability and
+  governance by business roles, and launchpad reachability now becomes a
+  federation question rather than a native one;
+- ADR-002's claim that "CAP exits the architecture" — ADR-001's CAP-first
+  direction is, in effect, back on the table.
+
+Parked with this decision, not closed: V-2, V-3, OQ-5, OQ-8, OQ-9, OQ-10 — all
+scoped to the parked development tenant. Each returns only with the RAP route.
+
+Unrelated to the decision but blocking any verification against the customizing
+tenant: the only `AZ_API_USER` credential for `my429480` in my estate is
+rejected (HTTP 401), the Cloud Foundry token is expired, and the client
+certificate path has no certificates. One of those has to be restored before I
+can read that tenant at all.