feat: add flowmesh stack bundle init

[kaiitunnz]

Purpose

Give pip-only deploy hosts a one-command bootstrap, and make the bootstrap role-aware so a worker bundle actually produces a worker-shaped deployment. flowmesh stack bundle export only works inside a repo checkout (it reads secrets/tls/* and configs/worker_config.yaml from CWD, and shells out to pip wheel ./sdk ./cli for the wheel bundle). A host that ran pip install flowmesh[cli] from PyPI has none of those sources, so the only way to land on the layout stack up expects was to produce a tarball elsewhere and tar -xzf it. And worker-mode bundles were previously half-broken: the tarball staging skipped the Redis cert/key files, but the chained flowmesh stack init still wrote a NODE_ROLE=root env that expected them.

Changes

• flowmesh stack bundle init scaffolds the deploy layout in-place (secrets/tls/{server,redis}/, configs/worker_config.yaml, .env) and chains stack init. Layout matches the shipped .env.example / compose.yml defaults, so stack up resolves to the paths the bundle wrote to.
• --role is end-to-end role-aware across stack init, bundle init, and bundle export <role>. Flips NODE_ROLE and blanks the Redis cert/key paths on worker; the worker bundle's install.sh propagates --role worker into its chained init. Worker bundle init next-steps now point operators at redis-ca.pem only, matching the scaffold.
• stack init --deploy pins FLOWMESH_VERSION to v<installed flowmesh-cli-stack version> (fallback latest+warning if metadata is missing). The v prefix matches the GHCR tag convention enforced by release-images.yml. bundle init implies it; bundle export's install.sh appends --deploy so CLI install and image pull land at the same version.
• install.sh anchors to the bundle directory via cd "$(dirname "$0")", so ./flowmesh_server_bundle/install.sh works from any CWD without scattering .venv, .env, or --include-wheels lookups outside the bundle.
• Drive-bys: lumid-hooks / lumid-data-sdk switched from git+url to PyPI pins; dead is_resource branch in assets.py removed (it was firing DeprecationWarning on every asset_path call).

Design

stack init now renders live from STACK_ENV_SCHEMA instead of copying the static .env.example. The shipped example stays the human reference, CI-verified against the root render. render_env_example takes an overrides map; WORKER_ROLE_OVERRIDES (next to the schema) holds the keys whose worker default diverges from root, and --deploy adds a single dynamic override for FLOWMESH_VERSION.

Image tag alignment happens automatically: bundle export's install.sh pins flowmesh[cli]==X and then runs stack init --deploy, which reads the just-installed package's version via importlib.metadata — same X — and pins FLOWMESH_VERSION=vX. No literal latest lives in the schema or override path.

bundle init is non-destructive: existing worker_config.yaml and TLS dirs are preserved; --force only governs .env. test_worker_role_render_passes_schema_validation pins the contract that rendered worker .envs are valid by the schema's own validators, so future drift trips at PR time, not on the deploy host.

Test Plan

uv run pre-commit run --all-files
uv run pytest tests --ignore=tests/worker/test_mp_executor_cleanup_gpu.py

Manual end-to-end smoke from a clean directory:

flowmesh stack bundle init --dest deploy --role worker
# verifies the worker .env shape, the scaffolded layout, the
# next-steps block staying accurate post-cd, REDIS_TLS_CA_FILE staying
# populated while cert/key are blanked, and FLOWMESH_VERSION pinned to
# v<installed flowmesh-cli-stack version>.

Test Result

$ uv run pre-commit run --all-files
# All checks passed

$ uv run pytest tests --ignore=tests/worker/test_mp_executor_cleanup_gpu.py
# 862 passed, 18 warnings in 29.87s

---

Pre-submission Checklist

• I have read the contribution guidelines.
• I have run `pre-commit run --all-files` and fixed any issues.
• I have added or updated tests covering my changes (if applicable).
• I have verified that `uv run pytest tests/` passes locally.
• If I changed shared schemas or proto definitions, I have checked downstream compatibility across Server and Worker.
• If I changed the SDK or CLI, I have verified the affected packages work (`uv sync --all-packages --group ci --frozen`).
• If this is a breaking change, I have prefixed the PR title with `[BREAKING]` and described migration steps above.
• I have updated documentation or config examples if user-facing behavior changed.