copilot_spaces: org-owned Spaces unreachable via the app's managed github MCP token (missing organization_copilot_spaces: read)

## Summary

`get_copilot_space` and `list_copilot_spaces` cannot read **org-owned** Copilot Spaces when called through the **GitHub Copilot app's** managed `github` MCP server. The same calls work from the **Copilot CLI**. Per this repo's README, org-owned spaces require a fine-grained PAT with `organization_copilot_spaces: read` installed on the owning org — and the app's auto-provisioned Copilot token appears not to carry that scope, with no user-facing way to add it.

## Environment

- Surface: GitHub Copilot **app** (built on Copilot CLI), MCP server `github` (`https://api.githubcopilot.com/mcp/`), toolset `copilot_spaces` enabled.
- Comparison surface: Copilot **CLI** ~v1.0.66 on macOS.
- Space under test: `GitHub Roadmaps Space`, owner `github`, URL `github.com/copilot/spaces/github/445` (org-owned).

## Steps to reproduce

1. In the **app**, call `get_copilot_space` with `owner: "github"`, `name: "GitHub Roadmaps Space"`. → **not found.**
2. In the **app**, call `list_copilot_spaces`. → returns only the user's own/bookmarked spaces; the org space is absent.
3. **Star/bookmark** `github/445` in the browser, wait ~1 day, repeat steps 1–2 in a fresh app window. → still **not found** / still absent.
4. In the **CLI**, call `get_copilot_space` with `owner: "github"`, `name: "GitHub Roadmaps Space"`. → **success, ~17 documents.** `list_copilot_spaces` returns ~505 org spaces.

## Expected

A user who has access to an org-owned space (and has starred it) should be able to read it via `get_copilot_space` / see it via `list_copilot_spaces` in the app, matching CLI behavior — or there should be a documented, user-actionable way to grant the app's `github` MCP token the required `organization_copilot_spaces: read` scope.

## Actual

Org-owned spaces are "treated as not found" in the app. The tools are **present** (so it's not a toolset-availability issue) but **fail** on org spaces. This matches the README's `copilot_spaces` authentication note:

> - Fine-grained PATs are not hidden by classic PAT scope filtering, so these tools may still appear even when the token cannot use them.
> - For org-owned spaces, fine-grained PATs must be installed on the owning organization and include `organization_copilot_spaces: read`.
> - If an org-owned space contains repository-backed resources, the token must also have access to every referenced repository or the space may be treated as not found.

## Root cause (hypothesis)

The app's managed `github` MCP token does not carry `organization_copilot_spaces: read` for the owning org (`github`), whereas the CLI's credentials do. Starring a space is a personal action and does not change the token's org scope, which is why bookmarking had no effect.

## Asks

1. Confirm whether the app's auto-provisioned Copilot token can include `organization_copilot_spaces: read` for orgs the user belongs to.
2. If not, document a supported way for a user to supply a fine-grained PAT (with that scope) to the `github` MCP server **in the app context**, the same way it works in the CLI.
3. Consider returning a **distinguishable auth/permission error** for org spaces instead of a generic "not found," so clients can tell "missing scope" apart from "wrong name" and guide the user.

## Impact

Tools/agents that pin org-owned Spaces (e.g. an internal PM router) work in the CLI but silently fail in the app, forcing a degraded "here's the URL, open it in your browser" fallback for every org Space.

Start with the README's copilot_spaces authentication note and the get_copilot_space and list_copilot_spaces entry points. Compare the app's managed github MCP token behavior with the CLI, focusing on organization_copilot_spaces: read and the generic not-found response. Done means the app supports the required access or documents a supported PAT path, with a distinguishable permission error where appropriate.

Escrita pelo modelo de indexação a partir do texto da issue.