Fix spacetime dev ignoring top-level module-path for generate entries

[clockwork-labs-bot]

Fixes #4651

When spacetime.json has a top-level module-path and generate entries:

{
  "module-path": "./server",
  "generate": [
    { "language": "rust", "out-dir": "./game_client/src/bindings" }
  ]
}

spacetime dev passed the generate entries to exec_from_entries without inheriting the top-level module-path. The generate step then fell back to the hardcoded spacetimedb default, failing with:

Error: Could not find module source at '.../spacetimedb'.

The standalone spacetime generate command already handled this correctly via collect_all_targets_with_inheritance() (which merges entity fields into generate entries), but spacetime dev bypassed that path and read config.generate directly.

Fix: Inject the top-level module-path into generate entries that do not specify their own, before passing them to exec_from_entries.

[clockwork-labs-bot]

To clarify the approach here: the generate_configs_from_file entries are only modified in memory — the Vec is cloned from the parsed config, and it's passed downstream as &[HashMap<...>] (immutable ref) to generate_build_and_publish. It never gets written back to disk.

The mutation inherits the top-level module-path into generate entries that don't specify their own, so downstream code (which reads module-path from each entry individually) picks it up correctly. Without this, entries without an explicit module-path fall back to the hardcoded "spacetimedb" default even when the user set a top-level one.

That said — happy to refactor this to resolve at read time instead (a helper that checks entry-level first, then falls back to top-level) if mutating a cloned config feels too smelly.