`++cut` jet mismatch for large spans

[dozreg-toplud]

To reproduce:

1. Switch test flag in _140_two_cut_a to c3n
2. Run in Dojo (set --loom to 33):

=a (cut 2 [0 (bex 31)] (bex (bex 33)))

You'll get:

mismatch: good 3a5bbd82, bad 79ff04e8

This is caused by the "rounding" of the argument c here when it's not a direct atom.

[joemfb]

That's interesting (and rough). That rounding behavior has been there forever -- I bet the increased loom size invalidated that behavior. u3a_maximum is properly defined in allocate.h, but you'd have to take the bloq size into account when comparing the step to it.

[dozreg-toplud]

@joemfb another example:

> (met 32 (bex (bex 33)))
1

It should've returned 3. It didn't because of the shortcut here.

[dozreg-toplud]

another mismatch of different nature: ++lte should return %.y if nouns are equal, even if both are cells. But in Dojo:

> (slum lte [0 0] [0 0])
dojo: hoon expression failed

[dozreg-toplud]

Similarly, ++lth should return %.n if both arguments are equal cells

[dozreg-toplud]

Resolved with #836 merged to 409