Collapses the per-member resume scan in getMemberSpawnStatuses into a single
readdir + file lock + pass over the team's tasks. Avoids N x IO when multiple
members become alive at launch. Semantics of the applied-set guard are
preserved 1:1; the single-member API stays as a wrapper around the batch.
readPersistedStatuses каждый раз делал полный sync-scan всех task
JSON под file lock и звал resumeActiveIntervalsForMember для каждого
member с runtimeAlive=true — на больших командах блокировал main
до 8s. Теперь маркируем member как 'resume applied' пока он остаётся
alive, сбрасываем маркер при переходе в not-alive (через
syncMemberTaskActivityForRuntimeTransition и в readPersistedStatuses
loop). Resume остаётся идемпотентным и материализует интервалы из
истории один раз за цикл alive.
Когда снимок liveness возвращает stale_metadata для direct-process
teammate с persisted runtimePid, который реально мёртв — собираем
кандидатов на очистку и сбрасываем их runtimePid/bootstrap-поля
из config.json через двойной чек под guard для запущенных run/launch
state. Это убирает мёртвые pid из последующих snapshot'ов и не
трогает OpenCode/lane-aware/runtime-session-имеющиеся записи.
Дополнительно добавлены targeted-pid liveness check (используется
расширение TeamRuntimeLivenessResolver.targetedProcess) и
shouldUsePersistedLaunchRuntimePidForMetadata, чтобы не подсасывать
устаревший pid в metricsPid для членов с lane-aware конфигурацией.
resolveBootstrapRuntimeEvidenceBoundaryMs учитывает оба источника
времени старта (firstSpawnAcceptedAt и bootstrapExpectedAfter) и
принимает более раннее, если у member и runtime совпадает
bootstrapProofToken + runId. Это лечит случай, когда proof подписан
до того, как app зафиксировал firstSpawnAcceptedAt, но после
bootstrap boundary самого ранкона. Та же логика применена в
isBootstrapMemberEvidenceCurrentForMember для confirmation evidence.
resolveTeamMemberRuntimeLiveness принимает опциональный targetedProcess
с pid + command — если строка процесса проходит team/agent verification,
liveness отмечается как 'runtime_process' даже когда полная process table
не нашла его (например при гонке snapshot vs spawn). Дополнительно для
direct-process backend разрешён fallback по --agent-name, когда команда
запущена без --agent-id.
Распознаём отдельную диагностику для EPERM на создании managed
node_modules symlink под Windows и подсказываем пользователю
запустить приложение от имени Administrator. UI-подсказка и
provisioning hint показываются только для этого случая, обычный
Windows access-denied flow не затрагивается.