Compile notes are untyped strings — add a severity/kind so consumers can render info vs warning without parsing prose

[pawellisowski]

Problem

aware app compile emits per-node compile notes as a bare notes: string[] on each lock node. The field mixes three semantically different things with no machine-readable distinction:

• Genuine warnings the author should act on — e.g. "agent X installed but command Y not found; defaulting to write-mode for safety" (a silent write-mode fallback is risky and worth surfacing).
• Benign provenance / info — e.g. "using author-declared mode: read" or "command exec is mode-overridable; using author-declared mode: read" (the compiler is just recording that it trusted the node-level mode: for a command whose mode it can't infer — FYI, not actionable). This is the common case for exec nodes (see Node-level mode: read on an exec node is silently overridden to write-mode at compile (no warning) #165).
• Errors — e.g. "agent X not installed".

Because there's no kind/severity, every downstream consumer has to string-match the note text to decide how loud to be. That's brittle and already bit us:

• floless.app (the web front door) rendered the strip as an amber ⚠ "warning" for what are usually benign exec provenance notes, and had a rewrite keyed on the literal substring "defaulting to write-mode". The 0.46 → 0.47 wording change (which switched to "using author-declared mode: read" as part of the Node-level mode: read on an exec node is silently overridden to write-mode at compile (no warning) #165 fix) silently broke that match — the UI fell back to showing AWARE's raw note verbatim. Matching on prose is inherently fragile across releases.

Proposal

Give each compile note a structured kind/severity. Minimal shape:

notes:
  - kind: info        # info | warn | error
    text: "using author-declared mode: read"

(or a parallel notes: [{ kind, text }] — whatever fits the lock schema; a back-compat option is a sibling note-kinds: [] if changing the element type is disruptive.)

Suggested classification of today's messages:

• "... command <c> not found; defaulting to write-mode for safety" (no author mode) → warn
• "... using author-declared mode: <m>" / "command <c> is mode-overridable; using author-declared mode: <m>" → info
• "agent <a> not installed; ..." → warn (or error if it blocks Run)

Why this is the right layer

AWARE owns the semantics (what a note means / how severe it is — it's the determinism/provenance authority that produces the lock). Consumers own presentation (how to show each severity). With a kind, every consumer — the CLI, the lock audit, floless.app — can render by severity (info quiet/collapsible, warn/error prominent) and stay correct across wording changes. Without it, each consumer re-derives severity from prose and rots on the next release.

Related

• Node-level mode: read on an exec node is silently overridden to write-mode at compile (no warning) #165 (honor author-declared mode: read on exec) — the fix that changed the note wording and exposed the brittleness. The notes themselves are correct now; this is purely about making their severity machine-readable.

Acceptance

• Each compile note carries a machine-readable kind (info/warn/error).
• The "used author-declared mode" notes are info; the "defaulting for safety" / "not installed" notes are warn/error.
• Documented in the lock-contract / app-spec so consumers can rely on it.