core: settle how a module appears in its own dependencies - #15119

This PR settles how a module appears in its own dependencies, in three commits.

1. Refuse a module whose main object is named after a core type

A module's main object takes the module's name and isn't namespaced, so a module named directory, container or file declares a type that core already has. Such a module should be refused when it loads, with type "Directory" is already defined by module "daggercore", and modules of SDKs without self calls (TypeScript, Python, Java, PHP) are. But for modules with self calls, which Go and Dang modules always have, the check only logged the clash and carried on (since #10584). The module's object type was then never installed, because the schema kept core's type of that name, while its constructor still replaced the core root field:

• Every call through the main object failed: in Dang with convert return value: expected string, got map[string]interface {}, in Go with cannot instantiate dagql.Class[*core.Directory].
• A Dang module that called the core root field it had replaced (a module directory calling Dagger.directory) hung on its first call.

Self calls add a module to its own dependencies, so its own types are found there. The check now accepts only that match and refuses any other clash, as for modules without self calls. This reverses the Go behaviour that #13381 described as "no longer fails the load".

That relies on a module's self dependency being the module itself. A module cloned into a new result (implementation scoping, SDK operation scoping) kept the self entry of the module it was cloned from beside its own, and would then have refused itself. The self entry is now marked, and attaching a module replaces it instead of appending a second one.

2. An entrypoint's schema never holds the module it builds

A version 2 manifest lists its dependencies as its entrypoint's own, and the entrypoint runs with a schema of the core and those dependencies. The module itself was added to that schema too. A module with the same name as one of its entrypoint's dependencies, such as a Go module named go, whose generated entrypoint builds it with dagger/go under the name go, then put two modules of one name into one schema: the entrypoint's go resolved to the module's own constructor, and the module failed to build. An entrypoint's schema is now the core and its own dependencies, never the module, and an entrypoint with no dependencies of its own runs with the core alone. The module's process keeps its self calls through the module's own schema.

3. A process an entrypoint starts runs as the client's own module

With the module no longer in its entrypoint's schema, a process the entrypoint starts couldn't find the client's module among the ones it serves, and fell back to a copy that keeps the source of whichever client loaded it first. The client's own module is now among the candidates.

What users see

• A Go or Dang module named after a core type now fails to load with the error above, instead of loading and then failing on every call (or hanging). As far as the tests and the code show, no such module works today.
• A module with the same name as one of its entrypoint's dependencies (such as a Go module named go) builds and runs.
• Speed: not measured; none expected. The refusal adds one identity comparison per module type at install, an entrypoint's schema holds one module fewer, and a process looking up its module has one more candidate.

Tests

• TestDang/TestMainObjectNamedAfterCoreType: a module container (failed with convert return value) and a module directory that calls Dagger.directory (hung; the test bounds it at 5 minutes).
• TestGo/TestMainObjectNamedAfterCoreType: a module directory that calls dag.Directory() (failed with cannot instantiate).
• TestModuleCloneRebindsSelfDependency: a self-calling module cloned into a new result has only itself as its self dependency, and its schema dispatches to it.
• TestModule/TestDangModuleEntrypointDependencySharesModuleName: a module named like its entrypoint's dependency; the entrypoint's call reaches the dependency.

Each fails without its fix. Without the third commit, four existing TestModuleLoading/TestServeModuleCallerTree cases fail.