fix: Extract Maintain() from Load() to eliminate side-effect coupling

[toasterbook88]

Addresses review feedback on PR #125.

• state.Load() no longer performs maintenance or re-saves
• Maintenance is now explicit via state.Maintain()
• Daemon, CLI, and tests updated to call Maintain() after Load()

All tests, race tests, lint, and coverage gates pass.

[gemini-code-assist]

Code Review

This pull request stabilizes the AXIS substrate by formalizing authority models, introducing a lifecycle taxonomy, and hardening state management. Key updates include establishing the reservation ledger as the canonical authority, implementing schema versioning for cluster state, and adding a pprof profiling flag to the daemon. Documentation is extensively updated with authority audits and decision records. Feedback identifies an unhandled error during state persistence in the daemon's refresh loop and recommends removing state-modifying side effects from the read-only Meta() function to ensure consistency.

I am having trouble creating individual review comments. Click here to see my feedback.

internal/daemon/daemon.go (488)

The error returned by st.Save() is being ignored. If saving the state fails after maintenance, the on-disk state will be inconsistent with the in-memory state used by the daemon, which could lead to correctness issues. This error should be handled, at a minimum by logging it, as this occurs in a background refresh loop.

                if err := st.Save(); err != nil {
                    slog.Error("failed to save maintained state", "path", state.Path(), "error", err)
                }

internal/daemon/daemon.go (661)

The Meta() function is intended to be a read-only operation, but it is performing state modification by calling state.Maintain(st). These changes are not persisted as st.Save() is not called, leading to repeated, inefficient maintenance on every call. More importantly, a read-only metadata endpoint should not have side-effects like state modification. The responsibility for maintaining state should lie within the daemon's main refresh loop (doRefresh). This fallback logic can lead to inconsistent views of the system state.

        // state.Maintain(st) // This is a read-only path and should not perform state maintenance.