feat: approved modelling and checkable quotes

[david-hudec-networg]

This is the improvements PR. It proposes a language change and amends a
recorded principle, so it is kept apart from
#46, which is bug fixes and should not
wait on a design debate.

Stacked on #46, so it shows that PR's commits too until it merges. The three
commits here are the last three.

One thesis: a workspace should be able to tell you what in it has been
approved, and let you check a quote against what was actually read. Today it
can do neither.

---

Where this came from

[@TomasProkop], reading the consulting plugin:

jestli uz bychom nemeli vynucovat entity/document mapping uz v insights,
protoze tam jsou nejaky random orders ktery jsou ambiguous a nedavaji smysl

nemuzes to tam nechat agenta najebat tisice zmen naraz … HITL u kazde zmeny,
approve/deny/modify

Both land, and the gap is measurable. On the engagement that prompted this, a
stakeholder confirmed 185 insights one at a time. The model was then derived
from them in a single pass of 41 elements — and that pass decided things the
evidence had not: that two roles named separately in the sources are one actor,
that three ways of starting a request converge on one process, and which of
three things a word meant, every time the sources used it for all three.

Every element carried a valid derivedFrom. Not one of those decisions had
been reviewed, and nothing in the workspace could tell you so. Traceability
and approval are different guarantees and the language had a field for one.

---

1. reviewStatus — approval of the modelling decision

proposed, accepted or rejected, on every element type that can cite
evidence: actors, entities, processes, steps, KPIs, value streams,
capabilities, hypothesis nodes, hypothesis trees and glossary terms.

Every one, because a rule that skips a type is a rule with a hole in it — and
the types most likely to be skipped are where the judgement is largest. Framing
the whole problem is a hypothesis tree. Deciding that three words the sources
use interchangeably name one thing is a glossary term, and getting it wrong
renames things across every other document. Those four types gain derivedFrom
too: approval without provenance records that somebody agreed and not what to.

Absent means not specified, and nothing more (P4.4). Reading silence as
accepted would manufacture the false comfort this exists to remove.

A rejected element is kept, not deleted. The record that a decision was
considered and turned down is what stops it being proposed again next quarter.

DD-012 answers the two rules this appears to cross. P1.4 assigns
proposed-versus-current to folders and git — but its "current/proposed" are
as-is and to-be states of a process, two models of a business rather than one
model awaiting sign-off; the collision is on the word. DD-011 rejected a
stored maturity because completeness is computable from what is present.
Approval is not: no amount of reading a model reveals whether a person agreed.

2. file — the text a quote can be checked against

P12.2 keeps information out of the workspace, on the grounds of size. That holds
for the artifact and not for its text. Five meeting transcripts are under 150KB;
the recordings are three orders of magnitude larger.

The schema already had both fields and they were not being used as intended.
url names the artifact, file is the text stored beside the workspace, and
validate now enforces what file always meant: a URL there is an error naming
url instead, and a path resolving to nothing is an error, because a dangling
pointer looks like filed evidence and is not.

The check found one on this repository. The example workspace declared a
transcript that had never been written — in the one place a reader looks to
learn the convention. It is written now.

Conversion stays out of UBML, and the pipeline records which converter it used,
because a quote that reads oddly may be the speaker or may be the converter.

3. ubml walk — the two halves reviewed together

walk next shows a claim beside the elements it proposes; walk set records
either half, the id saying which decision is being made. Reviewing a claim
without the element it would create approves the extraction and leaves the
interpretation unasked.

It shows the element in full. A reviewer asked to approve "a term, called X"
can only approve a name.

status gains deferred. proposed was carrying two meanings — nobody has
looked at this yet, and somebody looked and could not settle it. Deferring is an
answer: the reviewer reached the claim and decided not to decide, usually
because confirming it needs somebody who was not in the room.

---

Does it work

It was run to completion on the engagement above: 70 of 70 elements reviewed,
one at a time, 69 accepted and one rejected.

The review changed the model rather than ratifying it. Two entities turned out
to be one thing in two roles. A process was split, because a monthly invoice is
not a late step in one customer's request. A step left the model entirely
because it happens outside the application. One glossary entry claimed the
sources named a thing they never mention. One was rejected outright as a
platform concern a business twin has no reason to carry — and kept, with the
reason, so it is not proposed again.

None of that was visible before the elements were walked one at a time. That is
the argument.

Every defect the run exposed is fixed in these commits rather than described in
a skill: block finding that assumed a fixed indent, a parent inheriting its
children's state, a template-literal escape resolved before RegExp saw it,
elements that state themselves in term or text rather than name, a
confirmation line that counted the wrong thing, and a hypothesis tree with no id
type — writable and validatable, but impossible to reference.

npm test: 293 passed, 3 skipped.