feat(mdcode): guard the demo agent on rules stated in words

[libei]

Rebased onto main, which now carries #422 (the judge), #424 (AlloyDB as a second store) and #425 (the AlloyDB leg run for real). One commit, 28f69cb; the diff is this change alone.

The commerce demo declared three constraints as arithmetic and guarded on none of them, because nothing evaluates an expression yet. It now declares three more as sentences a judge settles, guards on those, and reaches all three of on_violation's outcomes against a live store.

What the demo shows

Request	Rule	Outcome
a $30 credit, ceiling is $25	CreditUnderReviewThresholdWithJudge	escalate — refused, and the refusal says an approver could allow it
a $5 credit, memo names no failure	CreditMemoNamesAServiceFailure	warn — written, with the warning in the same answer
$20 of $40, memo admits the split	CreditIsNotSplitToAvoidReview	reject — refused outright

The three expressions stay declared and unreferenced, as asked. Two of them compare the call against stored rows and stay expressions, for two different reasons -- CreditWithinOrderTotal because the judge this demo hires makes one model call with no tools, and OrderTotalMatchesLineItems because it constrains the state after the write, which nothing settled before the transaction can see. The third has a judged twin, marked temporary: once arithmetic can be settled by a query, settling it by a model call is paying for nondeterminism. That twin is named for the expression it duplicates with how it is settled on the end, CreditUnderReviewThreshold and CreditUnderReviewThresholdWithJudge, since the two are one rule down to the description and the suffix says which of the pair goes away.

Code

• modelTools takes a judge, so an action guarded by a judgment is offerable rather than withheld. The judge goes to the derivation rather than to each call — the same object has to answer runnable and answer the call, or a tool is advertised as callable and refused mid-call.
• kcmd agent tools --judge lists what such an agent is offered. No model is called: a judge settles a rule when an action runs, and a listing runs none.
• kcmd action list names --judge in its run: hint when a guard is judged.

The caution the docs now carry

The judge is instructed that arguments which do not contain enough to tell mean the rule does not hold, and that the reason says what is missing, so missing evidence is meant to refuse a call rather than pass it. That is an instruction to a model rather than a property of the runtime. An earlier wording of the memo rule on this branch is a case where the model did not follow it: a rule it had no evidence for came back held, the write went through, and no warning, log line or loader diagnostic said anything. The only way to know a judged guard works is to run a case it should refuse.

A second overclaim of the same shape was caught in review and is also gone: the docs said a rule comparing the call against stored rows has no judgeable wording at all. That is true of GeminiJudge, which makes a single model call with no tools, and not of Judge, which is an interface an implementation can satisfy by querying the store -- a reviewing agent that looks before it answers is how other systems settle exactly that rule. What survives is narrower and is about timing rather than visibility: a guard is settled before the transaction opens, so no judge, however much it can read, can be shown the state the write would produce.

An earlier draft of this branch claimed something stronger — that a judgment naming a stored field cannot fire. The actions guide's own worked example disproves it: a LineItem.memo judgment fails a call correctly there. Wording style is a risk factor rather than a law, and the documents say so at that strength.

Also in here

The AlloyDB walkthrough from #424 becomes step 8, since the outcomes it used to follow are now step 7, and it runs the credit that lands rather than the Labor Day request. That request is refused at a guard before a transaction opens, so against the second store it would have exercised nothing. Step 8's action run example needed the same treatment for the same reason: it now passes --judge and credits $20 rather than $30, and it and the psql output beneath it are recaptured from the AlloyDB cluster #425 used.

Verified

npm run compile clean, npm test 1067 pass / 0 fail, demo/semantic-model/agent && npm run check clean.

Against a real Spanner instance, on this commit: all four agent scenarios, both kcmd action run paths (with --judge it commits, without it refuses and names the two non-advisory guards), and every kcmd listing on the demo page diffed against its live run. The store was reset to seed state afterwards.

Two things worth knowing, both observed rather than inferred:

• The warn request does not always reach the tool. In roughly a quarter of runs the agent reads the advisory rule out of the tool description and declines before calling anything, which quietly turns an advisory rule into a blocking one. The README says so.
• Step 8's agent transcript is still uncaptured, as it was in docs(mdcode): the AlloyDB leg of the agent demo, run against a real cluster #425: @google/adk does not install against the internal registry on the machine with cluster access. kcmd action run covers everything under it, and the page says so.