feat: use git remote URL for cross-machine project memory sync

[jim80net]

Summary

Resolves #38

Uses git remote origin URL as the project identifier for memory container tags, enabling automatic cross-machine project memory synchronization.

Problem

Currently, project memories use sha256(directory) as the identifier:

• Different machines have different paths for the same project
• Result: project memories don't sync across machines
• Setting projectContainerTag affects ALL projects (memory pollution)

Solution

// Before
return `${CONFIG.containerTagPrefix}_project_${sha256(directory)}`;

// After
const remoteUrl = getGitRemoteUrl(directory);
if (remoteUrl) {
  return `${CONFIG.containerTagPrefix}_project_${sha256(remoteUrl)}`;
}
return `${CONFIG.containerTagPrefix}_project_${sha256(directory)}`;

Benefits

• Transparent: Works without user configuration
• Automatic sync: Same git remote = same project tag across all machines
• Automatic isolation: Different repositories stay separate
• Backward compatible: Falls back to directory hash if no git remote

Test Plan

1. Clone same repo on two different machines with different paths
2. Create a project memory on Machine A
3. Verify memory appears on Machine B
4. Verify different repos have different project tags

Example

Machine	Path	Git Remote	Project Tag
A	/home/user/projects/spark	git@github.com:user/spark.git	opencode_project_{hash(remote)}
B	/work/code/spark	git@github.com:user/spark.git	opencode_project_{hash(remote)}
C	/dev/other-project	git@github.com:user/other.git	opencode_project_{hash(other_remote)}

Machines A and B now share project memories. Machine C has its own isolated memories.

[jim80net]

Valid finding. Existing users have memories stored under sha256(directory). Switching to sha256(normalizeGitUrl(remoteUrl)) orphans those memories on upgrade — not just when adding a remote after creation.

Fixed in a88b0bd: all read operations (search, list, compaction context fetch) now query both the canonical remote-based tag and the legacy directory-based tag, deduplicating by memory ID. Writes go only to the new tag, so memories gradually migrate forward.

[jim80net]

Evaluated and this is not a real issue. The port number is part of the server identity — if a server runs on port 2222, all clones will include :2222 and they normalize consistently to gitlab.local/2222/user/repo.

The only failure case would be one machine using ssh://git@gitlab.local:22/user/repo.git (explicitly specifying the default port) while another uses ssh://git@gitlab.local/user/repo.git. This is vanishingly rare — no standard git tooling generates URLs with the default port.

Stripping port numbers would actually be worse: it would incorrectly unify repos from different servers on the same host but different ports (e.g., a staging and production GitLab on the same machine).

[jim80net]

Valid. All three merge sites now apply .slice(0, limit) after dedup. Fixed in ff06340.