Unify project item numbers across memories and tasks #73

Outcome

Every project-scoped memory, task and subtask receives one immutable public number from a shared project sequence. A future reference such as #42 resolves to exactly one item within its project.

Scope

• Keep typed memory/task models and internal identities; add a shared public reference registry or equivalent enforced model.
• Allocate numbers atomically across single writes, batch writes and concurrent agents; never reuse archived/deleted numbers. Gaps are acceptable.
• Define qualified references for other projects and personal/organization/device memories; bare #N must never guess a scope.
• Audit existing duplicate task/memory numbers and plan an explicit migration with legacy typed-route/API compatibility. Existing ambiguous bare references cannot be rewritten by guessing.
• Update UI, MCP schemas/descriptions, system guide and connection examples together; item resolution must respect access rights.

Delivery order

Contract and migration specification, allocator, migration, then resolver/agent contract. Safe Markdown rendering can proceed independently; automatic links depend on this epic.

Acceptance

• Concurrent creation cannot assign one public number to two project items.
• Old typed references still reach the original item or give a documented migration response.
• Agents resolve a bare project number before choosing memory/task tools.
• Authorization prevents private item discovery through lookup, titles or errors.

Agent handoff

Planning only in this session. Re-read current task and subtasks before implementation. Do not infer that internal IDs equal public numbers. Preserve existing data and test on a migration copy before production.

Concrete subtasks

1. #79 Reference contract and migration specification.
2. #80 Atomic allocator (after #79).
3. #81 Existing-data migration (after #79 and #80).
4. #82 Resolver and agent discovery (contract after #79; release after #81).

Related: #74 Markdown, #75 links, #76 blockers.