"Bake to Static Markdown" command to resolve VIEW/INPUT fields for external export tools

No files, tests, or entry points are named. Start by tracing the existing VIEW and INPUT resolution logic and command handling, then define the export path and output mode; done means static Markdown resolves the listed field types and supports the proposed in-place, parallel-file, or clipboard workflows.

Please fill out these Check-boxes

• I checked for existing similar feature requests
• I have read the docs and checked that the feature I am requesting is not already implemented
• My feature request consists of only one feature

Is your Feature Request related to a Problem or Annoyance?

When exporting Obsidian notes to PDF or other formats via external tools (pandoc,
obsidian-export, static-site generators, CI pipelines), VIEW and INPUT fields
are passed through as raw syntax (e.g. `VIEW[{process_owner}][text]`)
because those tools have no access to Obsidian's rendering context. Every external
tool that wants correct output must independently re-implement Meta Bind's field
resolution logic, including expression evaluation, render-type handling, and YAML
frontmatter parsing. This leads to fragile, duplicated implementations that diverge
from the canonical behaviour as the plugin evolves.

Describe the Feature you'd like

A "Bake to Static Markdown" command (similar to
obsidian-dataview-serializer
for Dataview) that resolves all Meta Bind fields in a note against its current
frontmatter and writes a static snapshot: either in-place, to a parallel file,
or to the clipboard.

Concretely:

• VIEW[{key}][text] → replaced with the plain-text frontmatter value
• VIEW[{key}][text(renderMarkdown)] → replaced with the raw markdown value
  (wikilinks, external links, etc. left intact for downstream tools)
• VIEW[{key}][date(YYYY-MM-DD)] → replaced with the formatted date string
• INPUT[...] / BUTTON[...] → stripped or replaced with their current value

The command could be triggered manually ("Bake current file") or as a pre-export
hook. The output is valid, portable Markdown that any tool can process without
knowing anything about Meta Bind.

Alternatives

• Official pandoc Lua filter: The maintainer publishes a .lua filter that
  reads pandoc's metadata block (frontmatter is already available there) and
  substitutes VIEW fields. Users pass --lua-filter=meta-bind.lua and get clean
  output. Narrower scope than the bake command (pandoc only), but very low
  maintenance burden.

• Standalone resolver package: A small, dependency-free npm/JS module that
  takes markdown content + a frontmatter object and returns resolved content.
  External tools import it instead of re-implementing the logic. Higher
  maintenance surface than either option above.

Additional Context

The Dataview Serializer plugin is a direct precedent: it runs inside Obsidian,
evaluates Dataview queries, and writes static Markdown back to the vault. The
same pattern applied to Meta Bind would immediately unblock export workflows for
pandoc, WeasyPrint, Hugo, Quarto, and any other tool that processes Markdown
outside Obsidian.

Research confirms there is currently no supported path to obtain fully-rendered
Meta Bind output outside the Obsidian Electron context (no headless mode, no
CLI, no existing Lua filter). A bake command would close that gap for the entire
ecosystem with a single, maintainer-owned implementation.