fix: ensure inputSchema always includes properties key for OpenAI-compatible clients

[asandres-eng]

Summary

• ToolRegistry.ts: In the list() method, normalize each tool's inputSchema to always include a properties key (falling back to {}). OpenAI-compatible clients (LM Studio, Claude Code) require properties to be present even when empty — without it they throw request.tools.[n].input_schema.properties: Required. Root cause: ArkType's toJsonSchema() for Record<string, unknown> emits {"type":"object","additionalProperties":{}} with no properties key.
• plugin-templater.ts: Change value imports from the obsidian package to import type. The obsidian package has "main": "" (types only, no JS entry point), so bun compile was failing to resolve it at build time. All usages were type annotations only — no runtime impact.

Test plan

• Run bun run check — no type errors
• Run bun test — existing tests pass (4 pre-existing failures in parseTemplateParameters unrelated to these changes)
• Run bun run build in packages/mcp-server — binary compiles successfully
• Call list_tools via MCP inspector — verify every inputSchema has a properties key, especially get_server_info and delete_active_file

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for superb-starlight-b5acb5 canceled.

Name	Link
🔨 Latest commit	a541f5b
🔍 Latest deploy log	https://app.netlify.com/projects/superb-starlight-b5acb5/deploys/69a79661d1b5df00080eae59

[istefox]

Hi @asandres-eng — heads-up that this PR will likely sit unmerged on the unmaintained upstream (per #79, declared 2026-04-24).

The equivalent fix shipped in the community fork istefox/obsidian-mcp-connector — closes upstream #77 (openai-codex / openclaw inputSchema validation). The fork's ToolRegistry.normalizeInputSchema() ensures every tool's inputSchema carries an explicit properties key, even for no-arg tools, plus strips the empty-object form of additionalProperties (#63 from upstream). Pinned by regression tests in toolRegistry.test.ts.

If you're consuming MCP-for-Obsidian from a strict-schema client (OpenAI Codex, Letta, etc.), 0.4.0 of the fork should work directly — the surface is HTTP MCP, no SDK shims required client-side. Thanks for the PR; the original problem signal was correct.