decision: split desired config from runtime state in machine.json

[mobileskyfi]

The decision

Whether to split desired config (cpu / mem / packages / networks) from runtime
state (pid / status / lastStartedAt) in machine.json.

Options

• Split into two shapes/files — clean separation; needs a field-split + migration.
• Keep a single shape, tag fields — lighter, less clean.
• Status quo.

Recommended default

Split, with a field-split + migration sketch — clarifies what is user-owned vs. derived.
Rationale in the DESIGN.md config note.

What it changes

The persisted machine.json schema and the public API that reads it. Needs a
migration for existing machines.

Done-when

Direction recorded; if "split", a Task with the migration sketch is filed; else closed.

[mobileskyfi]

Working a TOML-best "device inventory" file. While not saying it should be used per se. But we should try to align things so common attributes names are used.

Part of the issue here is XDG as config is different from state. Another part is reliability, in that if the runtime info is seperate there is little chance of ophaned machines if someone edits the machine.json.

This is a low priority item for quickchr.

However, aligning tikoci config files is a concern (e.g. so all share common vocab/style/directories/etc). So this more placeholder at this point...pending work on TikTOML, see tikoci/centrs#137 since while not directly linked.
We may want to adjust things in machine.json scheme - in some way - as a result, TBD.