create_issue requires a linked project account despite explicit repo_full_name

[Filed by Copilot on behalf of @bghgary]

### Short summary

The app-native `create_issue` tool requires the current project to have a linked GitHub account even when `repo_full_name` explicitly identifies the target repository.

### Affected version or release

GitHub Copilot app 1.1.14 (`0d498e8`)

### Installation context

Windows x86_64. The folder-project control had no linked repository or account; the GitHub-backed control used the same default signed-in GitHub account.

### What happened?

From a folder project, calling `create_issue` with `repo_full_name: bghgary/probe-241-does-not-exist` fails before repository lookup:

> This project's GitHub account is no longer available. Please re-link the project to a GitHub account before creating an issue.

The identical nonexistent target from a GitHub-backed project reaches `https://api.github.com/repos/bghgary/probe-241-does-not-exist/issues` and returns the expected 404. Neither control can create an artifact.

### Steps to reproduce

1. Add a folder project that is not linked to a GitHub repository.
2. Start a local session in that project.
3. Call `create_issue` with an explicit `repo_full_name` for an intentionally nonexistent repository.
4. Observe the project-account error instead of a repository-not-found response.
5. Repeat the same call from a GitHub-backed project and observe that the explicit target reaches the GitHub API.

### Expected behavior

When `repo_full_name` is supplied, `create_issue` should use the signed-in account that can access that target. The current project's GitHub account association should only be required when the destination must be inferred.

### Additional context

The folder project's database row has no `github_account_id`, while the app has a valid default signed-in account. The native handler returns in 0 ms without issuing an API request; the linked-project control reaches the explicit target in 408 ms.

`update_pull_request` and `reply_and_resolve_review_thread` show the same project-account precheck with explicit targets, suggesting a shared resolver. This report remains scoped to the verified `create_issue` failure.

Authenticated `gh` remains a working fallback.

Start at the app-native create_issue entry point and trace how an explicit repo_full_name is resolved before the project-account precheck. Compare that path with the behavior described for update_pull_request and reply_and_resolve_review_thread, then verify that explicit targets use the signed-in account while inferred destinations still require the project association.

Written by the indexing model from the issue text.