feature: hoon evaluation in chat

[jamesacklin]

This PR resurrects the inline Hoon evaluation feature from the old Landscape (pkg/landscape in urbit/urbit) and adapts it for the modern environment.

This is feature-flagged for now and will require a lockstep update to both the back-end and the client.

Original PR made by @wca4a's Clawdbot implementation in #5428

Plan here: https://gist.github.com/wca4a/4274ee015c5de2ca320a5c67da92cf4d

Changes

Ship-side (Hoon)

• /ted/eval.hoon - Spider thread that evaluates Hoon code in a sandboxed environment
• /sur/eval.hoon - Structures for eval input/output
• /mar/eval/input.hoon and /mar/eval/output.hoon - Marks for JSON serialization

UI (TypeScript/React)

• evalApi.ts - API function to call the eval thread
• BareChatInput/index.tsx - Added eval mode state and handling
• MessageInputBase.tsx - Added eval mode toggle button (Code icon)

How it works

1. User clicks the Code icon to enter eval mode (button turns green)
2. User types Hoon code in the input
3. On send, the code is evaluated via the /ted/eval spider thread
4. The result is posted as a formatted message with the code and output

Security Model

• Code runs in a sandboxed environment with only [our now eny ..zuse] in the subject
• Scry (.^) is disabled - returns crash if attempted
• Uses mule for double-virtualization to catch crashes
• No side effects possible - pure computation only

Screenshots / videos

[jamesacklin]

@Fang- said the slop is fine. Since this has to wait for the back-end to update before the client, let's hold for now.

[Fang-]

fang said the slop is fine

Yeah but I haven't reviewed your changes yet. (;

[Fang-]

I don't think the !< is right? Isn't it always going to be [~ cord]? The empty string default doesn't make sense anyway, that'll syntax error.

Suggested change

	:: handle both CLI [~ cord] and HTTP cord
	=+ !<(arg-data=?(~ [~ cord]) arg)
	=/ input=cord
	?~ arg-data ''
	+.arg-data
	:: unpack arg with leading ~
	::
	=+ !<([~ input=cord] arg)

[Fang-]

Coin-toss on whether it makes sense to have a file for this one definition lol. Fine as-is, but it is funny.

[Fang-]

Suggested change

	(of-wall:format (~(win re (sell type.p.minted p.toon)) 0 80))
	(of-wall:format (wash [0 80] (sell type.p.minted p.toon)))

I guess I should also give a heads-up that the outer +of-walls throughout the file will append trailing newlines. If that's objectionable you'll want to (zing (join "\0a" the-walls)) instead, to only insert newlines in between the lines.

[Fang-]

Kingside or queenside formatting for ?-, take your pick. (For %2 too.)

Suggested change

	%0
	=/ result=tape
	(of-wall:format (~(win re (sell type.p.minted p.toon)) 0 80))
	[%& (crip result)]
	%0
	=/ result=tape
	(of-wall:format (~(win re (sell type.p.minted p.toon)) 0 80))
	[%& (crip result)]
	::

Suggested change

	%0
	=/ result=tape
	(of-wall:format (~(win re (sell type.p.minted p.toon)) 0 80))
	[%& (crip result)]
	%0 =/ result=tape
	(of-wall:format (~(win re (sell type.p.minted p.toon)) 0 80))
	[%& (crip result)]

[Fang-]

Previous implementation was fine structurally, just needed to swap out the status value.

Suggested change

	?- -.eval-output
	%& (pairs:enjs:format ~[['status' s+'ok'] ['output' s+p.eval-output]])
	%| (pairs:enjs:format ~[['status' s+'error'] ['output' s+p.eval-output]])
	==
	%- pairs:enjs:format
	:~ ['status' ?-(-.eval-output %& s+'ok', %| s+'error')]
	['output' s+p.eval-output]
	==