Cancellation leaves a hung app-server alive — reproduction and tested fork fix

[mattpolicastro]

Removing a required approval label can clear an issue from Symphony's running map while its app-server OS process remains alive. I reproduced this twice on macOS arm64 with the official v0.0.2 runtime and a synthetic app-server that acknowledges startup, then stops reading stdin. One orphan survived Symphony shutdown with parent PID 1.

I have a tested, focused fix on a fork:

• Patch and regression tests
• Reproduction and limitations
• Compare against upstream

The fix gives the app-server port a separately supervised owner that monitors the consuming task. It sends TERM to the local process group and escalates to KILL, including for children that ignore TERM. It preserves the existing stdio protocol and does not change scheduling policy.

Validation:

• New cancellation regressions applied to unmodified upstream: 2 tests, 2 failures.
• Patched Linux make -C elixir all: 307 tests, 0 failures, 6 skipped; 100% coverage; lint and Dialyzer pass.
• Native macOS app-server and lifecycle suites: 27 tests, 0 failures.
• Original macOS label-removal probe: the worker exits without manual cleanup after the patch.

The base is e0ccc83720a42a600a53b61c5f8d3e518bebe1db; its app-server and orchestrator files match the release. Tests use synthetic processes and need no model credentials. This is local process-group cleanup, not containment for deliberately detached processes or a guarantee about remote SSH workers. Abrupt VM termination is also outside the patch.

I tried opening an upstream PR, but GitHub's GraphQL API returned a CreatePullRequest permission error and the REST create-PR endpoint returned 404. Issues are disabled, so I am sharing the reproduction and patch here. Is a PR from this fork welcome, or is there another preferred submission route?