Fix js_repl view_image test runtime panic (openai#11796)

## Summary
Fixes a flaky/panicking `js_repl` image-path test by running it on a
multi-thread Tokio runtime and tightening assertions to focus on real
behavior.

## Problem
`js_repl_can_attach_image_via_view_image_tool` in  

`/Users/fjord/code/codex-jsrepl-seq/codex-rs/core/src/tools/js_repl/mod.rs`
can panic under single-thread test runtime with:

`can call blocking only when running on the multi-threaded runtime`

It also asserted a brittle user-facing text string.

## Changes
1. Updated the test runtime to:
   `#[tokio::test(flavor = "multi_thread", worker_threads = 2)]`
2. Removed the brittle `"attached local image path"` string assertion.
3. Kept the concrete side-effect assertions:
   - tool call succeeds
- image is actually injected into pending input (`InputImage` with
`data:image/png;base64,...`)

## Why this is safe
This is test-only behavior. No production runtime code paths are
changed.

## Validation
- Ran:
`cargo test -p codex-core
tools::js_repl::tests::js_repl_can_attach_image_via_view_image_tool --
--nocapture`
- Result: pass


#### [git stack](https://github.com/magus/git-stack-cli)
- 👉 `1` openai#11796
- ⏳ `2` openai#11800
- ⏳ `3` openai#10673
- ⏳ `4` openai#10670

Author: fjord-oai

codex-rs/core/src/tools/js_repl/mod.rs

@@ -1746,7 +1746,7 @@ console.log("cell-complete");
         Ok(())
     }
 
-    #[tokio::test]
+    #[tokio::test(flavor = "multi_thread", worker_threads = 2)]
     async fn js_repl_can_attach_image_via_view_image_tool() -> anyhow::Result<()> {
         if !can_run_js_repl_runtime_tests().await {
             return Ok(());
@@ -1795,7 +1795,6 @@ console.log(out.output?.body?.text ?? "");
             )
             .await?;
         assert!(result.output.contains("function_call_output"));
-        assert!(result.output.contains("attached local image path"));
 
         let pending_input = session.get_pending_input().await;
         let image_url = pending_input