Prototype manifest v2 Go SDK

[shykes]

Purpose

This draft is an inspiration prototype for manifest v2. It tests how much of the hardened Go SDK can move to user space before the engine loader is complete.

@vasek @eunomie: Please review this for inspiration as the manifest v2 design develops. The main review points are the shared codegen boundary, the two-pass generation flow, and the generated entrypoint.

Design

• Keep one source for the existing client renderer, Go analyzer, validation, codecs, pragmas, source maps, static dispatch, and self-call generation.
• Keep helpers/module-codegen as orchestration only.
• Generate an embedded client below internal/dagger without a nested go.mod.
• Replace currentFunctionCall with an immutable DaggerDispatch function.
• Generate cmd/<module>-dispatch, a Dang ModuleEntrypoint, and the exact v2 dagger-module.toml fields.
• Merge the module schema in user space for self-call bindings.
• Type-check each generated Dang entrypoint against the proposed interface and the selected Dagger schema.
• Find go.mod above the module directory. Mount only that Go root for the dispatch build.
• Keep this SDK module loadable with manifest v1 and engine v1.0.0-beta.11. Do not write that legacy version into the generated v2 manifest.

The design note is in design/manifest-v2-prototype.md.

Current limits

• The engine manifest v2 loader is not complete. Normal module loading cannot run the generated entrypoint yet.
• Engine tests are still required for source resolution, type binding, constructor selection, result conversion, cache policy, currentNode, recursive module drivers, and legacy-loader selection.
• generate-v-2 uses the bundled beta.11 core schema for an engine-independent development path.
• A generated Go module must use an importable root package. package main is rejected with a migration message.
• The generated process transport is private to this prototype.

Validation

• dagger check e-2-e: 24 checks passed.
• go test ./... passed in all four helper modules.
• The generated manifest matches the design example.
• The generated Dang source satisfies the proposed ModuleEntrypoint interface.
• The generated module compiles and supports developer and engine dispatch.
• Dispatch tests cover constructor state, strings, lists, optional values, enums, void values, errors, nested Dagger calls, and core object ID round trips.