[Feature] Add drop-in mod package format with optional DevKit install tooling

[yunnwi]

Problem / Motivation

Installing runtime-loaded mods currently requires too much manual file copying and instance layout knowledge.

For example, installing a worldgen mod may require copying:

• the compiled .wasm artifact
• mod.toml
• experience.stack.toml
• world_preset.toml

into different instance directories, then also knowing when to delete world_bootstrap.toml or recreate the world so the new preset takes effect.

This is acceptable while developing a mod, but it is not good for normal users or larger reusable mods.

For normal player-facing mod UX, Freven should support a drop-in package workflow similar to mature modding ecosystems: download one mod package, put it in a mods directory, and let the platform discover, validate, and load it.

A CLI install command can still be useful for developers, server admins, package managers, and future launcher integration, but it should not be the only long-term user workflow.

This matters more as mods become more than a single wasm file. A Freven mod package may need:

• mod.toml
• Wasm/native/external artifact
• assets
• config schema/defaults
• optional experience layer
• optional world preset
• docs/readme

The platform should understand that package shape instead of requiring every user or mod author to manually copy files into multiple internal instance directories.

Proposed solution

Add a first-class drop-in mod package format, with optional DevKit tooling for install/validate/uninstall/update.

Example package:
yunnwi.terrain-0.1.0.frevenmod

This could be a zip-style package with a stable internal layout.

Conceptual contents:
mod.toml
yunnwi_terrain_mod.wasm
assets/
config.schema.toml
experience.stack.toml
world_preset.toml
README.md

Primary player-facing workflow:

1. Download yunnwi.terrain-0.1.0.frevenmod
2. Put it into an instance mods directory, for example:
   instances/my_instance/mods/yunnwi.terrain-0.1.0.frevenmod
3. Launch Freven.
4. Freven discovers the package, validates it, and makes it available to the active experience or mod selection flow.

Optional DevKit/admin workflow:
./freven_boot mod install yunnwi.terrain-0.1.0.frevenmod --instance instances/my_instance
./freven_boot mod validate yunnwi.terrain-0.1.0.frevenmod
./freven_boot mod list --instance instances/my_instance
./freven_boot mod uninstall yunnwi.terrain --instance instances/my_instance

Expected platform behavior:

• discover drop-in packaged mods
• validate package metadata and compatibility
• load mod.toml and artifact from inside the package
• expose clear diagnostics for missing/invalid files
• support assets inside the package
• support config schema/defaults inside the package
• optionally expose included experience layers/world presets
• avoid requiring users to manually copy files into multiple internal directories
• warn when a package affects world bootstrap, worldgen, vertical contract, or requires a new world
• avoid silently overwriting user-edited files
• provide a stable package contract that a future launcher/mod browser can use

For normal Vanilla add-on mods, the ideal player flow should be close to:
download package
drop into mods folder
enable/select if needed
play

For worldgen or total-conversion mods, the platform should make the extra requirements explicit:
this package provides/requires a world preset
this package changes world bootstrap
create a new world or reset existing bootstrap before use

Alternatives considered

1. Manual copying

This works for development, but it is too error-prone for users. It requires knowing the instance layout and which files belong under mods versus experiences.

2. Require an explicit install command for every mod

A CLI install command is useful for developers, server admins, automation, and future package managers, but it should not be the only player-facing workflow.

For normal users, dropping one package into a mods directory should be enough for discovery and validation.

3. Distribute only the .wasm file

This is not enough for real mods. The artifact usually needs mod.toml, assets, docs, config schema, and sometimes experience/world preset files.

4. Tell every mod author to write their own install script

This does not scale. Every mod would invent a different installer and users would get inconsistent behavior.

5. Require users to edit experience files manually

This may be acceptable for modpack authors, but not for normal users installing a single mod.