Expose explicit sync support/local usage metadata in project listings

[groksrc]

Feature / UX Request

Add explicit local-usage/sync-support metadata to project listing output so Team workspace projects cannot be misread as "not configured yet" when local sync is actually unsupported.

Problem

Today, project listing output includes fields such as:

• local_path
• cloud_path
• cli_route
• mcp_stdio
• sync
• workspace_type

For Team/organization workspace projects, sync: false and an empty local_path are technically correct, but they are ambiguous. Consumers may interpret them as "local sync has not been set up yet" instead of "local sync is unsupported for this workspace type."

Proposed Solution

Add explicit structured metadata, for example:

{
  "sync_supported": false,
  "sync_reason": "organization workspace",
  "local_usage": "cloud-only"
}

For Personal workspace projects where sync can be configured:

{
  "sync_supported": true,
  "sync_reason": null,
  "local_usage": "sync-supported"
}

Exact field names are flexible; the important thing is that machine consumers and humans can distinguish unsupported from merely unconfigured.

Acceptance Criteria

• bm project list --json exposes sync/local-usage support status explicitly.
• MCP list_memory_projects / project discovery exposes equivalent metadata.
• Text/table output communicates Team workspace projects as cloud-only or local-sync-unsupported.
• Existing fields remain backward-compatible where possible.

[claude]

Claude finished @groksrc's task in 2m 42s —— View job

---

Triage Analysis

• Gather context and read the issue
• Explore relevant codebase (project listing, schemas)
• Check for duplicate issues
• Add appropriate labels
• Provide triage summary

---

Classification

Attribute	Assessment
Type	Enhancement — adding metadata to existing project listing output
Priority	Medium — UX/correctness improvement, not data loss or breakage
Components	CLI (project list), MCP (list_memory_projects), cloud
Complexity	Medium — logic partially exists; needs surfacing in output

Labels applied: enhancement

---

Related Issues (same author, same root cause)

This issue is part of a cluster addressing Team/organization workspace handling:

• MCP project listing attaches local state to same-name Team workspace projects #848 (bug) — MCP listing incorrectly attaches local state to same-name Team workspace projects
• Block rclone sync/bisync commands for Team workspaces with clear errors #849 (enhancement) — Block sync commands for Team workspaces with clear errors
• Expose explicit sync support/local usage metadata in project listings #850 (this issue) — Expose sync_supported/local_usage metadata in listings

These are distinct but strongly related. Fixing #848 (incorrect state attachment) should be done first; this issue (#850) adds the explicit metadata that makes the state machine self-documenting.

---

Code Analysis

Good news: the core logic already exists in the CLI. Line 620 of src/basic_memory/cli/commands/project.py already computes:

sync_supported = cloud_workspace is None or cloud_workspace.workspace_type == "personal"

The gap is that this value is used internally for display but not exposed in JSON output (--json flag) or in the MCP tool response (list_memory_projects).

Affected locations:

1. MCP merge functions (src/basic_memory/mcp/tools/project_management.py):

   • _merge_projects() lines 107–131 — merged dict has no sync_supported field
   • _merge_workspace_projects() lines 163–205 — same
   • _format_project_list_text() line 210+ — no sync-support text for org projects

2. CLI JSON output (src/basic_memory/cli/commands/project.py):

   • The row_data dict built around lines 620–671 could include sync_supported and local_usage fields but doesn't currently

Proposed fields (aligned with issue proposal):

# Personal workspace or local-only project
"sync_supported": True,
"sync_reason": None,          # or omit
"local_usage": "sync-supported"

# Organization/Team workspace project
"sync_supported": False,
"sync_reason": "organization workspace",
"local_usage": "cloud-only"

---

Implementation Notes

The change is straightforward because the workspace_type is already available at merge time:

• workspace_type == "personal" or workspace_type is None (local-only) → sync_supported = True
• workspace_type == "organization" → sync_supported = False, local_usage = "cloud-only"

The main work is:

1. Add sync_supported, sync_reason, local_usage to both merge function dicts
2. Ensure --json CLI output includes these fields
3. Update text/table output to show "cloud-only" for org workspace projects
4. Add tests covering the new fields in both CLI and MCP tool output

This is a good medium-complexity enhancement that would be a natural companion to #848 and #849.