fix(runtime): native state polling remounts an active sandbox and causes HTTP 409

## Problem

During a running native task, polling the self-hosted thread state endpoint rebuilds its graph before a terminal snapshot exists. Graph construction verifies mounted skill files through another adapter sharing the executing sandbox session. These reads compete with execution for the session's exclusive slot and can produce HTTP 409.

## Reproduction and fix

A local cross-language test uses the real SessionManager HTTP handler and HttpSessionSandbox. While an execution holds the session slot, the old state route performs another mounted-file read, receives an actual HTTP 409, and fails the state request. Reusing the active graph's checkpoint read avoids this contention.

The fix must preserve fresh state, isolate resumed runs, and release graph references on completion/cancellation/publication failure. Retain only bounded sandbox conflict codes and do not let cleanup errors obscure the initial failure.

## Acceptance

- Concurrent state reads do not create another native graph or access mounted files.
- The real HTTP race test passes without 409; reverting the state route makes it fail.
- Resume and cleanup regression tests pass.
- Browser document generation is revalidated after deployment; this issue does not claim deployment completion.

Start at the native state route and trace the active graph's checkpoint read, then inspect the SessionManager HTTP handler and HttpSessionSandbox used by the local cross-language test. Run the real HTTP race test plus the resume and cleanup regression tests. Done means concurrent reads avoid mounted-file access and native graph creation, conflict codes remain bounded, and cleanup does not mask the initial failure.

Written by the indexing model from the issue text.