Expose gin/gorm symbols to Yaegi so dynamic plugins can implement every hook

[compscidr]

Current state

Dynamic plugins (ENABLE_DYNAMIC_PLUGINS=true, loaded by Yaegi from plugins/dynamic/*.go) can only use the Go standard library and the goblog/plugin package (plugin/symbols.go). The Plugin hooks whose signatures name third-party types therefore can't be implemented dynamically:

Hook	Blocked by
TemplateData(ctx) gin.H	gin.H
ScheduledJobs() []ScheduledJob	ScheduledJob.Run func(db *gorm.DB, …)
OnInit(db *gorm.DB) error	*gorm.DB
RenderPage(ctx, pageType) (string, gin.H)	gin.H

So today a dynamic plugin is limited to metadata, Settings, TemplateHead and TemplateFooter (documented in the README and in plugins/dynamic/hello.go.example, #554). Anything that touches the DB, runs on a schedule, feeds template data, or owns a page has to be compiled in.

Proposal

Generate Yaegi symbol maps for the relevant third-party packages and register them in the loader alongside stdlib.Symbols and plugin.Symbols:

yaegi extract github.com/gin-gonic/gin
yaegi extract gorm.io/gorm

• Put the generated files in their own package (e.g. plugin/symbols/) so they don't bloat plugin/ and can be regenerated with go generate. They will be large; check whether a subset (e.g. gin.H, *gin.Context, *gorm.DB and the query surface) is enough, or whether whole-package extraction is simpler to maintain.
• Yaegi's extract output is Go-version-tagged (//go:build go1.26); pin the generation to the module's Go version and regenerate when it changes. Both packages are already pinned in go.mod via Renovate.
• Extend the loader test to load a dynamic plugin that implements TemplateData, ScheduledJobs, OnInit, and Pages/RenderPage, so the new hooks are exercised in CI.
• Update the README "Limits of the interpreted environment" paragraph and the example's header once the limit is lifted.

Why it matters

The plugin directory (#552) and in-admin install/update (#553) only make sense for dynamic plugins, and with the current limit most interesting plugins (anything with data or a page) can't be distributed that way.

Trade-off

Dynamic plugins already run arbitrary Go in-process; this widens what that code can reach (full DB access) but doesn't change the trust model — the directory must remain operator-controlled and curated.

Related: #551, #552, #553, #554.

[compscidr]

Superseded by the WebAssembly plugin architecture (#575, #578; spec docs/superpowers/specs/2026-09-18-wasm-plugins-design.md).

The premise here was that the directory only makes sense for dynamic plugins and that Yaegi plugins can't implement the hooks that matter. Both were decided the other way:

• The directory is WASM-only, and the Extism host contract already covers every hook in the table above — template_data, jobs/run_job, on_init, pages/render_page — without exposing gin.H or *gorm.DB: templates get JSON, jobs get a per-plugin KV store, pages return a template name plus data. goblog-plugin-scholar (a page + a scheduled job + persistent state as one .wasm) is the proof.
• Exporting gin/gorm into Yaegi is the thing we chose not to do: it would tie every dynamic plugin to goblog's pinned gin/gorm versions, need symbol regeneration on every Go bump, and hand arbitrary in-process Go full DB access. Yaegi's role is now explicitly the operator-local, stdlib-only path (README "Dynamic plugins"), and that limit is part of the trust model rather than a gap.

Anyone wanting DB/page/job hooks builds a wasm module (GOOS=wasip1 GOARCH=wasm go build -buildmode=c-shared, see docs/PLUGIN_CONTRACT.md).