App manifest: add explicit autostart flag for boot-time launch

[woltspace-jerpint]

Problem

Today, what an app should do on container boot is implicit. apps_restore() infers intent from runtime state: a state file in .space/apps/<name>.json means "user wants this on." The state file is written when start_app() runs, and only deleted by explicit stop_app().

This works, but the source of truth is wrong. Boot-time intent is a property of the app, not of "did someone hit start once and not stop it." Reading wolts/apps/<name>/woltspace.json should tell you whether the app comes up on boot — without rummaging through runtime state.

A side effect of the current model: the PID liveness check (os.kill(pid, 0)) can in theory hit a false positive on PID reuse after container restart, where a recycled PID makes apps_restore think the app survived when it didn't. Small surface, but it's a symptom of overloading runtime state with intent.

Proposal

Add an explicit autostart: bool field to the woltspace.json manifest.

{
  "name": "corework",
  "start": "node server.js",
  "port": 4006,
  "public": true,
  "autostart": true
}

On container boot, after apps_restore() runs (preserving today's behavior), call a new apps_autostart() which iterates discover_apps(), filters to autostart=true, and calls start_app(name) for each. start_app is already idempotent (returns existing state if PID is alive), so apps already brought up by apps_restore are a no-op.

Default: autostart: false — no behavior change for existing manifests. Wolts opt in.

Why this matters now

Two wolts (Loup, lolo's lab) have been working around this by writing wolf.json cron entries with action: script to keep their apps alive (see #347). That's the symptom of "I want my app on after restart" not having a clean expression in the platform. Wolf is for scheduled wolt sessions, not service supervision. The right answer for "keep my app alive" is a property of the app manifest.

Scope

MVP:

• Add autostart: bool = False to WoltspaceApp schema in container/lib/apps.py
• Add apps_autostart() function
• Wire into FastAPI lifespan after apps_restore()
• Tests: parsing, idempotent skip when already running, no-op when autostart=false

Not in scope (follow-ups):

• Demoting state files from "intent" to pure runtime status
• PID + create_time hardening to eliminate PID-reuse false positives
• Lodge UI checkbox to toggle autostart per app

Migration

Existing users who relied on "start once via lodge/CLI, expect restart-restore" continue to work via apps_restore. Lolo + Loup add autostart: true to each service's woltspace.json and drop the wolf-cron workaround.