feat: support module_version for add-to-app releases

[eseidel]

Summary

• Flutter tool: Read SHOREBIRD_MODULE_VERSION env var in compileShorebirdYaml() and write module_version into the compiled shorebird.yaml (same pattern as SHOREBIRD_PUBLIC_KEY)
• Engine: No changes to release_version handling — host app version passes through unchanged
• Updater: Parse module_version from shorebird.yaml, add to UpdateConfig and PatchCheckRequest as a separate optional field sent alongside release_version

Context

Part of shorebirdtech/shorebird#793

release_version always stays the host app's version. module_version is a separate field used for patch lookup in add-to-app releases where the module's identity is independent of the host app.

Companion PRs:

• CLI + protocol: feat: support module_version for add-to-app AAR releases shorebird#3674
• Updater: feat: plumb module_version through as a separate field updater#329
• Server: https://github.com/shorebirdtech/_shorebird/pull/1974

Test plan

• Existing Flutter tools tests pass
• Existing engine tests pass
• Verify module_version appears in compiled yaml when env var is set
• Verify compiled yaml unchanged when env var is absent

[eseidel]

Design discussion: module_version vs release_version in the protocol

The current approach in this PR works by having the engine substitute module_version (from shorebird.yaml) into the release_version field that gets passed to the updater. This means:

• Pro: No updater (Rust) changes needed — the updater already receives release_version as a string and doesn't care where it came from.
• Pro: No server/database changes needed — release version is just an opaque string.

However, this means the host app's actual version is thrown away. The server has no way to distinguish a module version (git hash) from an app version, and can't report which host app versions are running a given module.

Alternative: plumb module_version as a separate field

Instead of overriding release_version, the engine could pass both values to the updater:

• release_version — always the host app's version (from PackageInfo)
• module_version — from shorebird.yaml, nullable

The updater would then send both in the PatchCheckRequest. The server would look up patches by module_version when present, falling back to release_version. The host app version could be stored for analytics.

This requires touching more code:

• Updater (Rust): Add module_version to AppConfig, PatchCheckRequest, and the check logic
• Server: Update patch lookup to prefer module_version over release_version
• Protocol: Add module_version field to PatchCheckRequest
• Engine (C++): Pass module_version as a separate field rather than overriding release_version

But avoids future problems:

• No polluted release_version data (git hashes mixed with semver app versions)
• Host app version still available for analytics/debugging
• No protocol migration needed later if we want both values
• Cleaner semantics — each field means exactly one thing

Recommendation

The current PR is a valid MVP, but we're leaning toward plumbing module_version as a separate field through the full stack (updater → server → protocol) to keep the data clean. This PR's engine + Flutter tool changes would still be needed either way — the difference is whether the engine overrides release_version (current approach) or passes module_version alongside it.

Leaving this here for discussion before we decide which path to take.