Add Northstar launcher and editor entry points

[re-oh]

What changed

• adds northstar-launcher as the default workspace executable
• adds Launch Northstar and Launch Northstar Editor actions
• adds a minimal northstar-editor application shell
• launches sibling binaries when available and falls back to Cargo in development
• documents launcher scope and adds workspace wiring

Why

Creates the central entry point for launching the game and editor, with room for mod/profile configuration in later iterations.

Stack

This PR targets northstar-ui-0.1-dev and should be reviewed/merged after the UI SDK PR.

Validation

• cargo check --workspace
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace
• bare cargo run launcher startup smoke test

[re-oh]

Direction for the launcher/editor shell

This PR should reflect the clarified UI scope: the UI toolkit is for the Northstar editor, with optional debug-only reuse in the game. It is not intended to become the general runtime game UI.

The editor executable should compose three distinct layers:

1. northstar-editor-core: persistent View identity, lifecycle, state serialization, close blocking, and workspace requests;
2. the Northstar-owned editor UI/layout model: panels, tabs, docking, focus, widget state, and saved workspace structure;
3. a Bevy adapter/host that supplies the window, input translation, UI rendering, and Bevy-rendered world viewports.

A View should remain alive and keep its internal state while hidden, moved, docked, or placed in another tab container. The workspace—not the Bevy ECS hierarchy—should own open View instances and map them to the editor UI model. The current minimal editor shell does not connect northstar-editor-core::View to the panel/tab system yet; that missing seam should be documented explicitly, and a minimal adapter can be added once the UI model has been separated from Bevy entities.

For the main game, any editor UI dependency should be behind an explicit development feature such as debug-tools. It may expose diagnostics, inspectors, or simulation controls, but shipping game UI should not depend on the editor toolkit.

Please also clean up the application boundaries introduced here:

• update AGENTS.md: full-featured Bevy is allowed in the windowed application crates (northstar-game, northstar-editor, and northstar-launcher), while reusable/core crates keep narrow feature sets;
• remove the unused northstar-launcher entry from [workspace.dependencies] unless a real library target consumes it;
• keep launcher functionality separate from editor UI internals—the launcher starts/configures applications but should not own the editor workspace;
• show launch failures in the launcher UI instead of only logging them;
• prevent repeated clicks from spawning duplicate targets;
• retain/reap child process handles or define a deliberate exit/detach policy;
• keep the Cargo fallback explicitly development-only and report a missing development workspace clearly.

This PR is correctly stacked on the UI work and should remain blocked on that lower layer. Once the editor UI model/backend boundary is corrected in PR #1, this PR should update to use that structure rather than deepening the direct Bevy coupling.