patch_vault_file silently corrupts content when targeting headings in nested sections

[grimlor]

Summary

patch_vault_file fails silently when the target heading exists inside a parent section. Instead of raising an error, it appends a new heading at the wrong level, corrupting the document structure.

Root Cause

The tool constructs heading targets using only the leaf heading name (e.g., "Section B"), but the underlying obsidian-local-rest-api passes this to markdown-patch, which requires fully-qualified hierarchical paths (e.g., "Parent Section\x1fSection B" using the unit separator \x1f as delimiter).

When the leaf-only lookup fails, markdown-patch falls through to createTargetIfMissing: true behavior and appends a new heading instead of raising PatchFailed. The caller receives no error signal.

Related Issues

• coddingtonbear/markdown-patch#7 — replace + createTargetIfMissing causes silent corruption instead of raising PatchFailed
• coddingtonbear/obsidian-local-rest-api#221 — MCP tool constructs leaf-only targets with no way for callers to provide qualified paths

Reproduction

1. Create a vault file with nested headings:

markdown

   # Parent Section
   ## Section B
   Original content

2. Call patch_vault_file targeting "Section B" with a replacement
3. Observe: a new ## Section B is appended at the end instead of replacing the existing one; no error is raised

Expected Behavior

Either:

• Accept fully-qualified heading paths (e.g., "Parent Section\x1fSection B") so callers can precisely target nested headings, or
• Raise a clear error when the target heading is ambiguous or not found at the top level

Workaround

Use create_vault_file for full rewrites. Heading-targeted patches via patch_vault_file are unreliable for any non-top-level heading.