Problem matcher relative file path should be rooted in working-directory, not workspace

tl;dr: To resolve relative paths in an Issuematch, the workspace location is used, even if the step's working-directory points elsewhere, making it impossible to correctly parse relative file paths in error logs.

I am using actions to check docstring code snippets ("doctests") in a Python codebase during documentation generation using Python's well-known documentation generator Sphinx. In typical Python codebases, the documentation resides in a subdirectory docs.

To run the doctest checker, you go to the docs subdirectory and run a sphinx-generated makefile with make doctest (which then uses sphinx-build).
I do this in a step by using working-directory:

      - name: Run doctests
        working-directory: ./docs
        run: |
          echo "::add-matcher::.github/sphinx.json"
          make doctest

I can tell that this works because the run step concludes correctly.
I have written a problem matcher (which you see added above) for this output. It has been simplified to account for the current lack of support for multi-line error messages. The problem matcher picks up the error messages correctly.

Now, crucially, doctest errors are reported by sphinx-build with relative paths relative to the docs directory where all the documentation and its configuration system reside. Using make -C docs doctest or similar things does not change that.

File "dev/adding_instruments.rst", line 321, in default

This file is in docs/dev/adding_instruments.rst related to the project root.

Another path referring to a file in the main python package looks like this - note the ... The line number being ? is a limitation of Sphinx.

File "../pymeasure/instruments/agilent/agilent34450A.py", line ?, in default

The annotation does not identify these paths correctly, despite the working-directory being used in the step definition:

Note that the line number and message are correctly picked up. The fact that this gets attributed to the .github "file" is https://github.com/actions/toolkit/issues/473

I found no way to get the Annotations to be placed/recognized correctly. fromPath cannot be used because the error message does not know about the project root location. I think I have identified the relevant code section which suggests that the workspace root is used for rooting, not the working directory.

Expected behavior

Having an error message with a relative path in file, and using working-directory in the step definition, I expected the relative path to be resolved correctly by rooting in the working directory, and the annotation to be placed in the PR Files view.

I am assuming that if working-directory is unset, it defaults to GetGitHubContext("workspace"). If that is so, a change of IssueMatch rooting to working-directory should show no change for people not using working-directory, limiting the impact of a fix for this issue.

Related issues

https://github.com/actions/toolkit/issues/224 by @xt0rted, apparently solved by @ericsciple but apparently not for a script step (non-container? I am not familiar with the lingo)
https://github.com/actions/runner/issues/659, which maybe could be solved at the same time if monorepos are restricted to using working-directory. This could limit scope so only use cases where the steps don't cd all over the place during execution would be supported.

Runner Version and Platform

2.273.5

OS of the machine running the runner? OSX/Windows/Linux/...
ubuntu-latest

Job Log Output

I can't offer debug logs as I don't have admin access to the repo in question, but the relevant run log starts [here].(https://github.com/ralph-group/pymeasure/runs/1302687942?check_suite_focus=true#step:6:1)

Start by reading Runner.Worker/Handlers/OutputManager.cs around lines 275-283 and trace how problem-matcher file paths are rooted when a step uses working-directory. Reproduce the documented Sphinx doctest case with relative paths; done means annotations resolve from the step directory while steps without working-directory retain workspace-root behavior.