OpenHands Fork Audit - MEDIUM: Fork-delta maintenance risk — carried patches must survive upstream merges

FLEET AUDIT FINDING: OpenHands Zentra fork — fork-delta correctness audit

Location: patches/sdk/README.md (documents 7 carried SDK patches), vendor/ (baked patches)

Severity: MEDIUM (P2) — Maintainability/correctness risk on upstream merge

The Issue:
The Zentra fork carries 7+ critical hardening patches baked into vendored source:

• 0001, 0001-critic: cloud-proxy neutralize
• 0002: stream-only no-op
• 0003: strict-OpenAI-compat request body filter
• 0004: thinking toggle
• 0005: universal call-boundary air-gap guard (CRITICAL)
• LMNR: observability gate
• Plus agent-server patches in api.py, conversation_service.py, conversation_router.py, etc.

If upstream OpenHands is pulled/merged into this fork, these patches could be:

1. Silently reverted (if the upstream re-adds code we stripped)
2. Moved to new locations (if upstream refactors the module)
3. Conflict with upstream changes (if upstream modifies the same lines)

Current risk mitigation:

• The verify_sdk_hardening.py script ASSERTS the sentinels are present (e.g., "ZENTRA-SDK-PATCH-0005" string)
• Boot-time assert_sdk_hardened() fails loud if a sentinel is missing
• But there is NO integration test that exercises the behavior (see GH OpenHands/software-agent-sdk#4262)

Potential gap:
If upstream OpenHands is merged WITHOUT re-running the vendor build + the verifier, a stale closure could ship with patches reverted.

How to mitigate:

1. Add a CI gate that runs verify_sdk_hardening.py on every vendor/ change
2. Add a pre-merge checklist to any PR that touches patches/ or vendor/: must re-run the verifier and commit updated vendor wheels
3. Document the patch series in patches/sdk/README.md with:
   • Why each patch is needed (security, telemetry, correctness)
   • What upstream code it modifies + line numbers (for merge conflict detection)
   • How to re-base the patch if upstream refactors the module
4. Add a "re-vendor check" workflow: after any upstream merge, automatically rebuild vendor/ and assert the verifier passes

Current documentation:
patches/sdk/README.md exists and documents the patches, but it's not wired into a merge workflow.

Start with patches/sdk/README.md and verify_sdk_hardening.py, then inspect the vendor/ tree and the existing patch sentinels. Run the verifier to understand its current coverage. Done means vendor changes and upstream merges have an automated verification path, with the required re-vendor and patch-maintenance steps documented.