feat(checks): cover workspace configs in a git subdirectory

[TomChv]

Every workspace the checks built put dagger.toml at the git root, so nothing covered the monorepo layout where several project workspaces sit in subdirectories of one repository. That is the shape dagger/dagger#13889 is about: the workspace root is the git root, so the caller's cwd sits below it, and module paths cross the engine ↔ SDK boundary workspace-root-relative while the selected config reads them relative to itself.

Adds a monorepo group building a third workspace — dagger.toml in common/, the SDK vendored under it, every command driven from common/.

Checks

Check	Asserts	On beta.9
installs-from-subdir-config	sdk install registers the SDK in common/dagger.toml	✔
explicit-path-keeps-module-whole	module init --path writes the module config at the requested path and nothing outside it	✔
scaffolds-module-from-subdir-config	module init writes common/.dagger/modules/subdir-mod/dagger-module.toml	✘
keeps-module-under-subdir-config	module init writes nothing outside the module directory	✘
subdir-module-loads	the scaffolded module generates and serves its API	✘

The three failures are one engine defect and stay red until it is fixed. They assert the contract rather than a convention (the module's files land with its config, in the directory the selected config points at), so they hold whichever side is reconciled.

The defect

core/schema/workspace_module_init.go computes the module path workspace-root-relative, writes the module's dagger-module.toml there, then records that same path in a config whose sources resolve relative to its own directory:

relPath = filepath.Join(".dagger", "modules", args.Name)   // root-relative
...
cfg.Modules[args.Name] = workspace.ModuleEntry{Source: relPath}   // written into common/dagger.toml, read relative to common/

Line 110 already resolves the runtime ref with moduleEntrySourceWithPinRelativeTo(staged.ConfigDir, relPath, sdkEntry), so the engine knows about ConfigDir-relative resolution — the module entry just doesn't use it.

The default-path case fails worse than the issue reports

The issue describes go-sdk erroring with outside changeset root. sdk-sdk stages files without the cwd-scoped polyfill fork, so nothing raises — module init silently writes the whole module, config and sources, at the git root:

$ git status --porcelain -uall
 M common/dagger.toml
?? .dagger/modules/subdir-mod/dagger-module.toml
?? .dagger/modules/subdir-mod/main.dang

while common/dagger.toml registers source = ".dagger/modules/subdir-mod", read relative to common/. The workspace is broken from that point on — any later command that loads it fails with local path "/work/common/.dagger/modules/subdir-mod" does not exist. No error, no warning, corrupt workspace.

No SDK-side fix reaches this. Prefixing the SDK's changeset with ws.cwd moves only the SDK's half and splits the module, leaving the engine's dagger-module.toml stranded at the git root — the engine computes the path before calling initModule, and validateSDKInitChangesetOwnership rejects an SDK that writes the module config itself.

Note on --path

An explicit --path deliberately skips the [modules.<name>] entry — usingDefaultPath gates it — so the module is authored rather than installed and there is nothing to load by name. Verified identical at a git-root workspace, so it is not a monorepo defect. explicit-path-keeps-module-whole therefore asserts co-location, which is what the issue actually reports there: the engine's module config and the SDK's files landing in two different directories.