Drop the polyfill for native workspace APIs

[grouville]

The Go SDK no longer needs dagger/polyfill.

Managed modules come from currentModule.asSDK(workspace: ws).modules, using the registrations already present in dagger.toml. Generation now keeps the workspace it received, applies each module's generated files to it, then returns only the difference:

before := ws
after  := moduleSource.generate(before)
return after.changes(from: before)

That explicit baseline matters during module initialization: the input already contains the new config and scaffold, so the SDK sees those files without returning them a second time. Paths are made cwd-relative once, by Workspace.changes(from:).

Init, clients, and config edits use the same pattern, and the polyfill dependency is removed.

Module generation writes a directory, not a workspace

ModuleSource.generate(workspace) is the API meant to replace the polyfill here, and its documentation promises the baseline survives:

The workspace change baseline is preserved, so a later Workspace.changes call includes this generation together with any other edits made by the caller.

On v1.0.0-beta.10 it does not. Applying a changeset to a workspace and diffing it back reports the module's entire generated context as added rather than only what generation changed:

$ dagger module init go myapp -y
$ rm .dagger/modules/myapp/dagger.gen.go
$ dagger generate --no-apply
.dagger/modules/myapp/.gitattributes     +3
.dagger/modules/myapp/.gitignore         +1
.dagger/modules/myapp/dagger-module.toml +5
.dagger/modules/myapp/dagger.gen.go      +255
.dagger/modules/myapp/go.mod             +53
.dagger/modules/myapp/go.sum             +97

Six files for a one-file change, including dagger-module.toml, which the SDK must never touch. Reduced, the round-trip loses the baseline on its own:

let gen = ws.moduleSource(p).generatedContextChangeset   # 1 added path
ws.withChanges(gen).changes(ws)                          # 9 added paths

A directory overlay does not have this problem, so generation writes generatedContextDirectory into the workspace instead. That context holds only generated files, so it is merged onto the module rather than replacing it, and Workspace.changes is left to do the cwd rooting and the outside-the-cwd guard as intended. dagger generate reports 1 file changed again, from the workspace root and from inside the module directory alike.

This should collapse to moduleSource.generate(ws).changes(ws) once the engine's changeset baseline is fixed, and the merge step goes away once Workspace grows a layering withDirectory.

generateModuleCheck now commits the fixture's .gitattributes so a generator returning its whole context is caught: every other file in that fixture is genuinely new, which is why the suite stayed green through this.

initModule layers, it does not replace

Workspace.withNewDirectory replaces the directory it writes, where the polyfill's fork.withDirectory layered onto it. That is what generateClient wants — its input already carries the existing client directory, so replacing prunes stale generated files — but initModule must never remove anything. Running it over a directory that already held files removed that directory's dagger.json and its subdirectories; it now layers the starter onto whatever is already at the destination. e-2-e:init-over-existing-check covers it.

sdk-sdk pin

The pinned e1747f4 predates sdk-sdk#20, which made every check group honour the daggerCliVersion setting and moved its default to 1.0.0-beta.10. Before that the contract group built its target from mod-test's own default of beta.9, and a beta.9 CLI cannot see a function taking a required Workspace argument — so initModule was invisible and the four contract checks failed as "initModule should seed at least one SDK file", with module:loads failing the same way. Those seven checks are red on main today; the pin bump is a separate commit because it fixes them on its own.

Test

dagger check

53 checks, all passing: the e-2-e suite plus the dagger/sdk-sdk conformance groups.

Requires dagger/dagger#13854 and dagger/dagger#13855.