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, init changesets are applied at the root, and module paths reach the SDK relative to that root.

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

Rebased on main, which drives 1.0.0-beta.10.

Checks

Check	Asserts	beta.9	beta.10
installs-from-subdir-config	sdk install registers the SDK in common/dagger.toml	✔	✔
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	✘	✔
explicit-path-keeps-module-whole	a relative module init --path keeps the module whole under the caller's cwd	✘	✔
rooted-path-anchors-module-at-root	--path /<name> anchors the module at the workspace root	✘	✔

Five of the six fail on the pre-fix engine and all six pass on beta.10, so none of them are vacuous. The full suite is green: 31 checks.

What the engine fix changed

dagger/dagger#13890 closes the defect this branch opened red. Init now applies both changesets at the workspace root and hands the SDK a workspace whose cwd matches, so the two halves of a new module stop landing in different directories, and the default module path is anchored at the directory holding the dagger.toml being edited rather than at the workspace root — which is what [modules.<name>].source was already resolved against.

That fixes scaffolds-module-from-subdir-config, keeps-module-under-subdir-config and subdir-module-loads unchanged. On beta.9 they still fail exactly as this branch described:

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

$ dagger api functions subdir-mod
Error: local path "/work/common/.dagger/modules/subdir-mod" does not exist

The --path checks moved

The fix also changed module init --path deliberately: it now resolves against the caller's cwd, with a leading / meaning the workspace root, like every other workspace path a user types. It used to be workspace-root-relative.

explicit-path-keeps-module-whole passed common/subdir-path-mod — a root-relative path naming the config directory. Under the new resolver that means a common/ below common/, so the check was asserting the old spelling and failed on beta.10 by landing the module at common/common/subdir-path-mod. It now passes a relative path and asserts the module lands under the caller's cwd. Note this flips its beta.9 result: in its old form it passed there, because the old spelling was the correct one for the old resolver.

rooted-path-anchors-module-at-root is new, and covers the other half of the resolver. With the default path now anchored beside its dagger.toml and a relative --path resolved against the caller, a leading / is the only remaining way to hand the SDK a module path the caller's cwd does not contain — the shape a cwd-scoped SDK cannot stage at all. beta.9 rejected it outright:

Error: --path "/subdir-rooted-mod" must be workspace-relative, not absolute

Note on --path

Unchanged by the fix: an explicit --path deliberately skips the [modules.<name>] entry — usingDefaultPath still gates it — so the module is authored rather than installed and there is nothing to load by name. Both --path checks therefore assert co-location rather than installation, which is what the issue actually reports there: the engine's module config and the SDK's files landing in two different directories.