fix(flows): stop a recorded sub-flow pinning the device it was recorded on

[filip131311]

Fixes #607.

The bug

DEVICE_BIND_KEYS covered udid and device_id, but flow-execute's own device parameter is named device. So a recorded tool: flow-execute step kept the record-time id in the YAML, and on replay the runner never rebound it.

Reproduced live on 0.18.1. Recording a cross-project flow-execute step:

steps:
  - tool: flow-execute
    args:
      name: b-only
      project_root: /…/projB
      device: BC0026C7-AAE0-490E-8BD4-A345CF65FB1B   # survived stripDeviceKeys

Then editing that id to one that does not exist — what a flow committed on one machine looks like on another — and replaying against a real booted device:

flow-execute { name: pinned, device: BC0026C7-… }

  [1] ✓ flow-execute
  { "device": "00000000-0000-0000-0000-000000000000",   <-- baked in, not rebound
    "ok": false, "errored": 1,
    … "reason": "…[SimulatorServer:00000000-…] simulator-server exited…" }
  PASS — 1 passed, 0 failed, 0 errored

This contradicted three things the code and docs already claimed: that flows store no device id and are portable, that the runner is authoritative on device and drops any id stored in a step, and that device ids are stripped at record time.

It also made the raw tool: form behave differently from run: composition, which has always inherited the run device. That matters more than it looks: the recorder falls back to the raw form whenever the target is not a resolvable sibling, and always uses it for a remote recording, since run: composition is host-resolved. Remote recordings are therefore the main producer of the affected artifact.

The fix

Add device to DEVICE_BIND_KEYS. That fixes both halves at once — stripDeviceKeys keeps it out of new recordings, and bindDeviceArgs replaces an id already committed to a flow file.

Safe because bindDeviceArgs only injects keys the target tool declares, and across all 75 registered tools exactly one declares device — flow-execute itself. (24 use device_id, the rest udid; both were already bound.)

platform is deliberately not stripped

There is a test pinning this so a later symmetry edit fails loudly. Two independent reasons:

1. It is read only when no device was given — resolveFlowDevice returns on opts.device before touching it, and the chromium boot spec is gated on !params.device. Once device is bound it is inert.
2. The strip is schema-blind, and platform is not device-specific on every tool: react-profiler-analyze declares its own. Stripping it would silently rewrite a recorded Android profile analysis into an iOS one.

Verified live

replay, flow bakes in the all-zeros id, run given a real device:
  before -> nested device 00000000-…, ok false, errored 1
  after  -> nested device BC0026C7-…, ok true,  errored 0

record leg -> recorded YAML has no `device:` key

Five new tests, each confirmed to fail before the change and pass after: the two unit cases, an integration case through the runner, the record-side case (using a non-resolvable target — a resolvable sibling records as run:, which carries no args and so could never show this), and the remote-persist case. Full tool-server suite 3091 passing; lint, prettier, typecheck:tests and the tool-description gate clean.

Behaviour changes worth knowing

• Flows with a baked-in device stop pinning and follow the run device. That is the fix and the documented contract, but it is a silent semantic change for anyone who noticed the pinning and relied on it. No migration is possible or desirable — the baked-in id is host-specific and is exactly what made those flows non-portable.
• A nested flow-execute can no longer target a device other than its parent's. Verified nothing in the repo does this (no tracked .argent flows, no flow references in the e2e scripts or workflows), and run: already behaved this way. The loud case is a nested Chromium flow that used to boot its own Electron instance; the quiet case is a nested step with a different platform, which now silently runs on the parent's device.

Related

• flow replay: a raw tool: flow-execute step always reports PASS, whatever the composed flow did #606 (a nested flow's failure does not fail the outer step) is what let the transcript above report PASS. Independent in code — flow replay: a raw tool: flow-execute step always reports PASS, whatever the composed flow did #606 is in the result inspection after dispatch, this is in the args before it — so they do not conflict. Worth knowing when reviewing flow replay: a raw tool: flow-execute step always reports PASS, whatever the composed flow did #606 that the "nested run errored" symptom there had a second, separate cause, fixed here.
• extractDeviceArg in http.ts keeps its own parallel udid/device_id list and also omits device, so a top-level flow-execute call gets no platform attribution in telemetry. Not touched here — it is telemetry-only, and unifying it would create an import direction that does not exist today.
• project_root / flow_file are absolute host paths baked into recorded steps — the same portability family, but they cannot simply be stripped (the nested call needs them) and rebinding needs a design decision. Filing separately.