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.

Bắt đầu từ công cụ `store_memory` và theo dõi cách CLI suy ra mã định danh repository từ remote `origin`. Tái hiện lỗi sau khi thay đổi `origin` thành URL Azure DevOps được hiển thị, đồng thời so sánh hành vi ghi và đọc. Công việc được xem là hoàn tất khi các origin không phải GitHub không còn tạo ra kết quả từ chối truy cập gây hiểu lầm, và hành vi được hỗ trợ cùng thông báo lỗi được kiểm thử.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.