Memory sync now recognizes tombstones and won't silently resurrect deleted content

What

• When a memory write conflicts because the target was recently deleted elsewhere (a "tombstone"), it's now detected and reported as a distinct tombstone_conflict reason rather than a generic conflict.
• Multi-store (org/shared) memory sync checks for this on push: if a local copy predates the deletion and is old enough, it's silently deleted to match; otherwise the user is warned once per path instead of the file being endlessly re-pushed or silently recreated.
• Writing identical content back to a path that was just tombstoned is now explicitly refused with a dedicated error rather than going through generic conflict handling.
• The conflict-error type used for memory version conflicts now carries tombstone and deletedAtMs fields (with a matching deleted_at/conflicting_memory_id schema addition), including a fallback check for older messages that mark the conflict via a (tombstone_conflict) suffix.

Why Without this, deleting a shared memory entry on one machine could get silently undone when another machine's stale local copy synced back up. Now the conflict is detected and surfaced clearly, so a deletion actually sticks instead of being fought over by out-of-date copies.