Make module discovery cwd-aware and resolve dagger-module.toml

[TomChv]

What

Ports the cwd-aware module discovery change to the Java SDK, matching the sibling SDK PRs:

• go-sdk: module now respects cwd go-sdk#11
• python-sdk: feat: make Python module discovery cwd-aware python-sdk#9
• typescript-sdk: feat: make module discovery cwd-aware typescript-sdk#11

Tracking issue: dagger/dagger#13688.

Changes

• Mod.path → Mod.rootPath — the workspace-root-relative path is the module's stable identity. A new computed Mod.path is a cwd-relative view (".", "sub/mod", "..") so listings read the way a shell user sees them.
• JavaSdk.modules(ws) — new cwd-aware discovery. It goes through the polyfill's findConfigDirs (anchored at the client's cwd, not the workspace root) and intersects the result with the engine-owned currentModule.asSDK.modules list. generateAll now goes through it, so running from a subdirectory acts on the project you're in and the projects beneath it.
• dagger-module.toml resolution — module roots are discovered by either the CLI 1.0 dagger-module.toml or the legacy dagger.json (moduleConfigFilenames).
• Polyfill bump — points the polyfill dependency in dagger-module.toml (the effective module config, which still pointed at the old sdk-sdk/polyfill) at github.com/dagger/polyfill@main, which provides findConfigDirs.
• Workspace wiring — rewrites the stale workspace dagger.toml (it still referenced a Go-based runtime that has since moved to Dang) to register the e2e module and the java SDK with its fixtures.

Tests

Adds modulesCheck and modulesCwdCheck to the e2e module, covering discovery of both config formats, cwd walk-down/find-up scoping, and exclusion of modules this SDK doesn't manage.

Verified against a v1.0.0-beta.7 engine:

✔ e-2-e:modules-check OK
✔ e-2-e:modules-cwd-check OK
✔ e-2-e:init-check OK
✔ e-2-e:skip-generate-filename-check OK
✔ e-2-e:target-runtime-check OK
✔ dang-sdk:generate-all OK

Signed-off-by: Tom Chauveau tom@dagger.io