#2914 model cancel SIGTERMs a running swamp serve process when the method run belongs to a serve-run workflow

Description

swamp model cancel (src/cli/commands/model_cancel.ts) picks running model_method rows from the run tracker by model type only and calls killProcessTree on the row's pid. Workflow steps register those rows with ActiveRun.createModelMethodRun using pid Deno.pid and no instanceId (src/domain/workflows/execution_service.ts, src/libswamp/models/run.ts). swamp serve hands its runTracker to the WorkflowExecutionService it builds (src/serve/deps.ts) and shares the repo tracker database (RunTrackerStore.fromSwampDir).

So for a workflow that swamp serve is running, the step's tracker row carries the serve process's pid. swamp model cancel (or --all) passes isSwampProcess, sends SIGTERM to the serve process, and SIGKILLs it after the default 2 s, well under serve's 30 s shutdown drain. Every in-flight run on that server is cut off, not just the one method run.

workflow cancel already avoids this: isServeOwnedRun (src/cli/commands/workflow_cancel.ts) routes serve-owned runs through the server instead of killing a pid. model cancel has no equivalent, and the method rows carry no instanceId to tell them apart.

Found by code reading while triaging swamp-club#2910. Not reproduced end to end.

Steps to reproduce (suggested)

1. swamp serve in one shell, in a repo with a workflow whose step runs a long shell method (sleep 60).
2. Trigger the workflow through the server.
3. From a second shell in the same repo: swamp model cancel

Expected

model cancel never signals a serve process. Serve-owned method runs are either cancelled through the server or refused with a message pointing at the server, and method rows record the instanceId of the serve that owns them.

Actual (expected from the code)

The serve process receives SIGTERM and is SIGKILLed about 2 s later.