Fix relative path resolution in tool file readers

[reowszer]

Problem

File writers (smiles_to_coordinate_file, run_ase output) route relative
paths through _resolve_path into CHEMGRAPH_LOG_DIR. File readers didn't —
they opened the raw path from cwd. An agent that writes water.xyz then reads
it by bare name gets FileNotFoundError.

Seen with meta-llama/Llama-3.3-70B-Instruct on ALCF: it passes bare filenames
between tools. Models that pass absolute paths (e.g. gpt-oss-120b) avoid it.

Fix

Add _resolve_existing_path(); apply in run_ase, extract_output_json,
file_to_atomsdata, generate_html. Returns the path if it exists, else the
log-dir location, else raw (missing-file errors still surface). Absolute and
cwd-relative paths unchanged.

Tests

• tests/test_ase_input_path_resolution.py (EMT, no network): 5 pass.
• Full suite: 264 passed, 28 skipped. 3 failures in test_human_interrupt.py
  are pre-existing on dev (b10180a), unrelated.

[tdpham2]

Hi @reowszer. Thanks for PR. I think this is more an LLM issue (with generating the right tool call parameters, e.g file path), than an actual tool issue (e.g reproducible bugs even with frontier models on Argo).

All the tools should return the absolute path to the file that was written. A good model should be able to pick up the full path. For example, in smiles_to_coordinate_file, the tool returns the absolute path. Even though the agent may specify water.xyz, it should still know that the file written isn't ./water.xyz, but /path/to/water.xyz.

    return {
        "ok": True,
        "artifact": "coordinate_file",
        "path": os.path.abspath(final_output_file),
        "smiles": smiles,
        "natoms": len(numbers),
    }

[tdpham2]

Closing this. Feel free to reopen if any issues pop up!

[tdpham2]

@reowszer I reopened since I think this will help long-term for smaller models. Could you please help me check the related MCP tools current under dev and see if you can add a similar fix?

[reowszer]

The MCP tools have been checked, and the same _resolve_existing_path fallback added across their file readers (the _hpc and data_analysis/hpc_misc servers). graspa_core.py and xanes_core.py were also switched from Path(...).resolve() to the fallback so the single-structure _hpc path is covered; mcp_tools.py already inherited it by delegating to the patched core. The _hpc workers were left unchanged, since bare names are resolved before submission or by the now-fixed cores.

Two things worth a look: the fallback was also applied to the deprecated graspa_mcp_parsl.py / xanes_mcp_parsl.py for consistency, which can be reverted if deprecated code should stay untouched; and the three failing test_human_interrupt.py tests already fail on dev (from b10180a), so they look unrelated.

ruff passes; tests were added for the MCP and graspa bare-name paths.