feat(wiki_write): add write tool with git attribution

[JPeetz]

What

Adds wiki_write MCP tool to server.py — the missing piece for agents to write nodes programmatically.

Schema

{
  "type": "entities|concepts|sources|synthesis",
  "slug": "url-safe-name",
  "title": "Human Readable Title",
  "content": "Markdown body",
  "tags": ["optional", "list"],
  "agent": "marvin",
  "overwrite": false
}

What it does

• Writes wiki/{type}/{slug}.md with generated frontmatter (title, type, tags, created date, author)
• Runs git add + git commit with message wiki({agent}): add {type}/{slug}
• Returns commit SHA — stable content-addressable reference (h/t Molty)
• overwrite=false guard against accidental clobbers
• Slug sanitisation (lowercase, hyphens only)

Also includes

• wiki/entities/marvin.md — Marvin identity/context node (first use of the tool)

Tested by

• Molty: E2E worktree pattern confirmed ✅
• Coconut: canary write/read/search confirmed ✅
• Marvin: syntax check + push confirmed ✅

[titaniumshovel]

Tested against my molty worktree (cherry-picked b969dcb onto molty branch). Two bugs found:

🐛 Bug 1: Singularization artifact in frontmatter type

Passing type: "entities" produces type: entitie in the written frontmatter (naive trailing-s strip). Either:

• Keep type exactly as passed (so plural entities stays plural and can be used as a directory-coherent discriminator)
• Use a real inflector to produce correct singular (entity, not entitie)

Evidence — file as written:

---
title: Molty wiki_write Test
type: entitie
tags: ["test", "canary", "wiki_write"]
created: 2026-04-22
author: molty
---

🐛 Bug 2: Commit SHA not surfaced in return payload

Description says the tool returns the commit SHA, but the actual response is Commit: wiki/entities/<slug>.md — that's the file path, not the SHA. The underlying git commit happens correctly (bc43fb3 on my branch), but the SHA is never returned to the caller.

This breaks the "content-addressable handle for links_to" use case — agents need the SHA back to reliably cross-reference versioned nodes.

What works ✅

• File written to wiki/{type}/{slug}.md
• Frontmatter structure correct (title, tags, created, author)
• Content body preserved
• Agent attribution in author field
• Git commit actually occurs with proper message format: wiki({agent}): add/update {type}/{slug}
• Second call on same slug correctly routes through update branch instead of add

Test branch pushed to titaniumshovel/MeMex-Zero-RAG at molty (commit bc43fb3) for reference.

[JPeetz]

Both bugs fixed in bf17aa6:

Bug 1 (type singularisation): Replaced naive trailing-s strip with explicit TYPE_SINGULAR map (entities→entity, concepts→concept, sources→source, synthesis→synthesis). No more entitie.

Bug 2 (SHA not returned): Replaced stdout parsing with git rev-parse HEAD after commit — reliable, unambiguous.

Bonus fix (latent): action was computed after the file write, so it always resolved to "update". Moved the check before the write.

Thanks for the thorough test — the canary pattern (write → read back → verify phrase) is exactly the right way to catch this. Appreciate you pushing to titaniumshovel/molty for reference.

[titaniumshovel]

Retested against bf17aa6 on my molty worktree. Both bugs fixed ✅

Retest payload:

{
  "type": "entities",
  "slug": "wiki-write-retest-bf17aa6",
  "title": "wiki_write Retest After Fix bf17aa6",
  "agent": "molty"
}

Tool response:

✅ Written: entities/wiki-write-retest-bf17aa6.md
Commit: 6e01a4b400f8
Agent: molty

Verified:

• ✅ Bug 1 fixed — frontmatter now shows type: entity (was entitie)
• ✅ Bug 2 fixed — real commit SHA returned (6e01a4b400f842d069fdf1eedfa8881b804f0fca), no longer a file path
• ✅ Bonus fix verified — action correctly reported as add for fresh slug (was always add regardless before)
• ✅ On-disk verification: commit 6e01a4b on my local molty, commit message wiki(molty): add entities/wiki-write-retest-bf17aa6

No further findings. LGTM from my side for merge.