/memory shows invalid "Manage stored memories" link for non-GitHub repositories (404s)

[DrEsteban]

Describe the bug

When I run the /memory slash command inside a repository whose origin remote is not GitHub (in my case, an Azure DevOps repo), the command's output includes a Manage stored memories: https://github.com/<org>/<repo>/... link.

That URL is constructed from the local git origin's path and points at github.com, but the repo doesn't exist on GitHub — so the link opens a 404 page.

The link shouldn't be shown at all when the current repository's remote isn't hosted on GitHub.

Affected version

1.0.49-6

Steps to reproduce the behavior

1. cd into any local git repository whose origin remote points at a non-GitHub host (e.g., https://<ado-org>.visualstudio.com/<project>/_git/<repo> for Azure DevOps, or any GitLab/Bitbucket clone).
2. Launch copilot.
3. Run /memory at the interactive prompt.
4. Observe the output.

Expected behavior

The Manage stored memories: … link is omitted entirely when the current repo's origin isn't a github.com URL, since the URL the CLI would generate isn't valid in any other host's UI.

Ideally the CLI would detect the host of the origin remote and only emit a management link when it knows where the memory store actually lives on that host (today that appears to be GitHub-only).

Additional context

• OS: Windows 11 (PowerShell 7)
• The CLI itself works fine — memories are still being managed/loaded as expected. This is purely a misleading output artifact from /memory.
• Repro is independent of whether memory is currently enabled or disabled for the session.

[DrEsteban]

Related: #3060 reports the same root cause from a different angle — store_memory write failures (and a misleading error message) when the repo's origin isn't on github.com. The fix for both is the same underlying logic: detect that the current repo's origin isn't a github.com URL and adapt the behavior (here: suppress the link; there: emit a clearer error and/or allow an explicit memory-repo override).