I think the merge of last PR #81 left a small gap: local paths in remote actions.
This PR fixes it.

I try to explain the scenario below.

Remote Composite Local Path Resolution

The real-world scenario is this:

1. A workflow uses a remote composite action that lives in a subdirectory of another repository.

Example:

- uses: some-owner/some-repo/composite-actions/parent@v1

2. In that repository, the referenced action lives at:

composite-actions/parent/action.yml

3. The scanner loads that file because owner/repo/path@ref means "fetch path/action.yml from that repository at that ref".

4. Inside that composite action, one of its steps uses another local action via a relative path:

runs:
  using: composite
  steps:
    - uses: ./child

5. That means the composite action is delegating to another action located next to it:

composite-actions/parent/child/action.yml

So the chain is:

• workflow references some-owner/some-repo/composite-actions/parent@v1
• scanner resolves that to composite-actions/parent/action.yml
• inside that file it sees uses: ./child
• scanner should then resolve that to composite-actions/parent/child/action.yml

The key point is how GitHub treats ./child here.

At first glance, it is easy to ask whether ./child should be relative to the repository root. For composite actions, GitHub's docs point the other way: local uses: ./... references are relative to the composite action's own directory.

Relevant GitHub docs:

• Composite action tutorial:
  https://docs.github.com/en/actions/tutorials/creating-a-composite-action

  This says to use "the relative path to the folder where the composite action's action.yml file is located" in the uses key.

• Metadata syntax reference:
  https://docs.github.com/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions

  This documents local action references inside composite steps, for example uses: ./.github/actions/my-action.

Applied to this scenario, ./child inside:

composite-actions/parent/action.yml

should resolve relative to composite-actions/parent/, so the correct target is:

composite-actions/parent/child/action.yml

not:

child/action.yml

That is the bug fixed here: upstream currently resolves ./child as if it were repository-root-relative, but for composite actions it needs to be resolved relative to the directory of the composite action currently being expanded.