Generate and publish the extension API instead of hand-writing it

publicApi.d.ts and publicApi.js are now emitted from src/publicApi.ts by
`npm run build-types` and committed, and package.json's types and main fields
point at them. main.d.ts is deleted; it can no longer fall behind because it no
longer exists.

Pointing main at the generated shim also fixes the package as a runtime import.
It previously named main.js, which is gitignored and so was never actually
published — the entry point resolved to nothing. The shim is 1.7kb against the
bundle's 3.6mb, because getAPI only has to find the already-running host plugin
in Obsidian's registry; an extension that imports it gets a function, not a
second copy of this plugin. Obsidian itself loads plugins by manifest, not by
package.json main, so nothing about how the plugin runs changes.

A files allowlist keeps the published tarball to the two generated files plus
the manifest, readme and licence, rather than shipping src/, docs/ and the test
suites.

The remaining way for the output to fall behind is forgetting to regenerate it,
so `npm run build` now runs build-types and CI fails if the committed output
differs from a fresh build.

Verified end to end against a strict-mode consumer that imports every exported
name, registers routes and an MCP tool, and handles ApiVersionUnsupportedError:
it typechecks against the generated declaration, and require() of the package
root resolves getAPI and returns the expected values for absent host, present
host, and version-too-old.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>