docs/emitters: check dst against go/ast for the Go additive-merge adapter #794

Problem

docs/emitters/targets/go/emit.md and docs/emitters/targets/go/overview.md reserve go/ast for one job: re-parsing an existing generated file so the Go merge adapter (emitters/golang/mergeadapter.go) can append new top-level symbols and never delete. docs/emitters/write-integrate.md keeps user edits safe with two kinds of marker, @morphic:ignore-file and @morphic:keep / :end regions, both of which are comments.

go/ast stores comments by byte offset in a separate list rather than on the nodes they belong to. Inserting or reordering declarations in an ast.File and printing it back does not keep a comment with the declaration it described, and the position fix-ups needed to stop that are the part of AST rewriting that is easy to get subtly wrong. Region markers make that a correctness property here, not a cosmetic one: a marker that drifts off its region would let a later run overwrite hand-written code.

github.com/dave/dst is a decorated syntax tree: comments and spacing are attached to nodes and travel with them when the tree is modified, with decorator.Parse/Print for the round trip and import management built in. Its README calls the API stable. Its licence and recent activity have not been checked here and need confirming before any adoption.

Question

Does dst make the additive-merge adapter simpler or safer than go/ast plus go/printer, for the cases docs/emitters/write-integrate.md actually needs?

Proposed direction

A spike, not an adoption, since no emitter exists yet. Take a generated file containing @morphic:keep regions and detached comments, add one new top-level declaration and one new method with each approach, and compare the printed output byte for byte. Record the result and the licence and maintenance check in docs/emitters/targets/go/overview.md, whichever way it goes.

Acceptance

• docs/emitters/targets/go/overview.md names the library the adapter uses, or states why go/ast suffices, with the spike's evidence.
• If dst is chosen, the dependency is noted in the emitter layering section (emitters/golang only), and the archtest rules entry for that package allows it and nothing wider.