Implement internal APIs for list/get/download artifacts

[robherley]

Part of:

• https://github.com/github/actions-results-team/issues/2038

For list/get/download operations, we'll use the internal runtime JWT and validate the claims to determine artifact resource access & fetch internally. This is a minor improvement so that actions:read permissions (not default) are not required to get/list/download Artifacts that currently scoped to the current run. This is the same behavior to how lookups on Artifacts work today.

In the future, it'd be great if we can solely rely on public APIs with new fine grained GITHUB_TOKEN permissions, but there are other efforts blocking it at this time.

We'll still offer the ability to use the public API for convenience, each of the Artifact client methods has options which has an intersection type with FindOptions:

toolkit/packages/artifact/src/internal/shared/interfaces.ts

Lines 129 to 142 in a59f976

	// FindOptions are for fetching Artifact(s) out of the scope of the current run.
	// Must specify a PAT with actions:read scope for cross run/repo lookup otherwise these will be ignored.
	export interface FindOptions {
	findBy?: {
	// Token with actions:read permissions
	token: string
	// WorkflowRun of the artifact(s) to lookup
	workflowRunId: number
	// Repository owner
	repositoryOwner: string
	// Repository name
	repositoryName: string
	}
	}

We'll expose those as optional inputs on download-artifact, so there's a first class way to download artifacts from other repositories, e.g.

- uses: actions/download-artifact@v4 # not released yet
  with:
    name: my-artifact-from-another-repo
    github-token: ${{ secrets.token }} # requires actions:read
    repository: actions/my-repo
    run-id: 1234

[robherley]

I chose to change this, since the user agent header isn't always going to be for the upload or download artifact actions.

Having the pkg version will be more useful IMO

[robherley]

Removed this since we'll be getting the backend ids in multiple client methods. I'll leave it up to the caller instead to handle the rejected promise. The behavior of having it resolve and requiring a check on success is a bit odd IMO

[konradpabjan]

Overall looks good! Just some small questions