[Bug] Harness Browser: Live View "Take control"/"Release" breaks the agent's automation on SSO handback (workaround: interact without Take control + reconnect)

## Summary (corrected after further testing)

On a **managed AgentCore Harness** with the built-in **Browser** tool, you can let a human complete an interactive **SSO login** (e.g. IAM Identity Center / a federated QuickSight console where the OTP arrives by email) in **Live View** and then have the agent continue in the **same authenticated session** — **but only if you avoid the Live View "Take control" / "Release control" toggle.**

- **Broken path:** human clicks **Take control**, completes the SSO+OTP login, clicks **Release control**, then the agent resumes. → The agent's automation context is destroyed. Every subsequent automation call returns `Target page, context or browser has been closed`, and shortly after the backend reports it is gone (`not initialized` / "all sessions are gone"). The authenticated session is unrecoverable. Reproduced across 3 orchestration strategies (concurrent polling, blind hands-off, signal-gated hands-off where the agent provably never touched the browser during the human's control).
- **Working path (workaround):** human interacts in Live View **without** clicking Take control (types the OTP / completes login directly), then the agent, on resume, **does NOT reuse its pre-login page handle** — it **reconnects / re-reads the current page** (e.g. via `evaluate` / re-navigate). → The authenticated state **carries over**; the agent lands on the authenticated console and proceeds normally. Verified end to end against a real QuickSight Enterprise console.

So the issue is specifically: **the documented Live View take-over/release-control feature does not cleanly hand control back to the managed-harness agent's automation** (it tears down the automation context), even though the dev guide presents take/release control as a feature ("interactive controls to take over or release control from automation").

## Environment

- boto3 `1.43.29` (`bedrock-agentcore-control` + `bedrock-agentcore`), managed Harness (`CreateHarness`/`InvokeHarness`), browser `aws.browser.v1`, `networkMode: PUBLIC`, region `us-east-1`.
- Tools: `agentcore_browser` + `agentcore_code_interpreter` + inline functions; `allowedTools: ["*"]`.

## Repro (both paths)

1. Harness with `agentcore_browser`; invoke a task that navigates to an SSO-gated console URL. Agent lands on the sign-in page (expected).
2. Open the session's Live View.
- **(broken)** Click **Take control** → complete SSO+OTP → **Release control** → agent resumes → context dead.
- **(works)** Do **not** click Take control; complete the login directly in the stream → then the agent **reconnects** (re-reads the page rather than reusing the old handle) → authenticated session carries over.

## Asks

1. Is the **Take control → Release control** path *intended* to hand control back to the harness agent's automation? If so, the teardown is a bug; if not, please document that interacting **without** Take control (plus an automation reconnect) is the supported human-assisted-auth pattern.
2. Could the automation context **survive** a take/release cycle so the documented feature works for the managed harness?
3. Separately: the harness `agentcore_browser` tool config only accepts `browserArn` (no `profileConfiguration`), so a pre-saved authenticated browser profile cannot be attached as an alternative to interactive login. A `profileConfiguration` passthrough would help.

Happy to share CloudWatch DEFAULT-log-group traces for both the broken and working runs.