store_memory fails for repositories whose origin is not on github.com (e.g., Azure DevOps)

## Summary

The `store_memory` tool returns the following error for every write attempt in a repository whose `origin` remote points somewhere other than `github.com`:

> Unable to store memory. The repository may not exist or you may not have write access to it. You can continue with your task without storing this information.

Reads of previously-stored memories still succeed (they're surfaced in the system prompt as `Repository memories for owner/repo`), so the failure is write-only.

## Reproduction

1. Take any repo that has stored memories from when `origin` was on GitHub.
2. Migrate hosting (e.g., to Azure DevOps): rename the GitHub remote, set `origin` to the new host:
```bash
git remote rename origin github-archive
git remote add origin https://dev.azure.com///_git/
```
3. In a fresh `copilot` session, ask the agent to remember a fact (so it calls `store_memory`).

**Expected:** memory is stored.
**Actual:** every `store_memory` call returns the access-denied message above. Reads of the previously-stored memories continue to work.

## Diagnosis (best guess)

Memory is keyed by GitHub `owner/repo`. The CLI infers that identifier from the `origin` remote URL. After migration, `origin` is no longer a GitHub URL, so the backend can't resolve the identifier and the write is rejected with a permissions-shaped error.

Reads work because the memories were written when `origin` was still GitHub and persist server-side; the read path may key off a cached / historical identifier or off the system-prompt repository hint.

## Why this matters

Teams that host code outside GitHub but still use Copilot CLI lose all session-to-session persistence of standing rules and conventions. The error message also misleads users into investigating GitHub permissions when the real issue is the remote URL scheme.

## Suggestions

1. **Don't silently fail.** When `store_memory` is called against a non-GitHub repo, return a clear error (`"Memory store currently requires a GitHub origin; this repo's origin is ."`) instead of "the repository may not exist or you may not have write access" — the latter sends users on a wild goose chase through GitHub permissions.
2. **Allow an explicit override**, e.g., a `--memory-repo owner/name` flag, an env var (`COPILOT_MEMORY_REPO`), or a config key so a project hosted on ADO/GitLab/Bitbucket can pin its memory namespace to a sibling GitHub repo (often a mirror or an "ops" repo).
3. **Document** the GitHub-origin requirement in the README/help so users know up front.
4. **Long term**, decouple the memory namespace from the host (key by canonical workspace ID, repo path, or user-chosen string).

## Workaround I'm using

`AGENTS.md` at the repo root, which the CLI auto-loads every session per its docs. Captures the same standing rules, persists in git, and doesn't depend on the memory backend. Works well, but it's a workaround — multi-repo / per-user nuance that `store_memory` could express isn't replicable in a checked-in file.

## Environment

- macOS (Darwin)
- Repo originally on GitHub, migrated to Azure DevOps
- Multiple `store_memory` calls in a row, all returned the same error
- `githubstatus.com` shows Copilot operational at the time (no incident)

Happy to provide more detail or test patches.

Start at the `store_memory` tool and trace how the CLI derives the repository identifier from the `origin` remote. Reproduce the failure after changing `origin` to the Azure DevOps URL shown, comparing write and read behavior. Done should mean non-GitHub origins no longer produce a misleading access-denied result, with the supported behavior and error message covered by tests.

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