-build-file with a core seems stateful

[matthew-levan]

Describe the bug
Flipping the definition of a core in a file back and forth between two versions breaks the compilation via -build-file on the second flip. See reproduction. #5242 may be related.

To Reproduce
Steps to reproduce the behaviour:

1. Boot a fresh vere-v3.0 fakezod running urbit/urbit develop
2. |mount %base
3. Insert file to base/pkg/arvo/lib/vial.hoon with contents:

=>  ~
~%  %vial.100  %vial  ~
~%  %one  +  ~
|%
++  dec
  ~/  %dec
  |=  a=@
  ?<  =(a 0)
  =|  b=@
  |-  ^-  @
  ?:  =(a +(b))  b
  $(b +(b))
--

3. ~zod:dojo> =v -build-file %/lib/vial/hoon
4. Note successful compilation
5. Comment out L1 of vial.hoon
6. |commit %base then build again
7. Note successful compilation
8. Uncomment L1 of vial.hoon
9. |commit %base then build again
10. Note unsuccessful compilation with following error:

: /~zod/base/7/lib/vial/hoon
clay: read-at-tako fail [desk=%base care=%a case=[%da p=~2024.4.15..15.45.11..db28] path=/lib/vial/hoon]
/lib/vial/hoon:<[3 1].[13 3]>
/lib/vial/hoon:<[2 1].[13 3]>
/lib/vial/hoon:<[1 1].[13 3]>
[%error-building /lib/vial/hoon]
clay: %a build failed [%base 0v8.q04fc.o62on.0ebmp.nhrve.4uqd6.cnn50.mi4ue.b3fbs.stfgu.sbf55 /lib/vial/hoon]
> =vial -build-file %/lib/vial/hoon
thread failed: %build-file
[[p=~zod q=%base r=[%da p=~2024.4.15..15.45.11..db28]] s=/lib/vial/hoon]

Expected behaviour
It should build successfully, as it did the first time.

System (please supply the following information, if relevant):

• OS: macOS
• Vere and Urbit OS versions: vere-v3.0 and %411 (I think?)
• Your ship's %base hash: f6n8d

[sigilante]

Hypotheses we experimented with:

1. vial is getting shadowed in some weird way that breaks core builds.
2. The build subject is getting altered statefully in some opaque way.

[drbeefsupreme]

Great timing! Ran into this bug for the 3rd time today (over the last ~6 months) and had no idea what was causing it, and wasted an hour trying to get a repro without success. I was tempted to post a completely unhelpful issue saying "there's something wrong with the dojo subject but I don't know what" but wanted to gather more information from coworkers first. So thanks for finding a repro and posting this issue.

[matthew-levan]

Hypotheses we experimented with:

1. vial is getting shadowed in some weird way that breaks core builds.
2. The build subject is getting altered statefully in some opaque way.

Yes. To test 1's viability, we renamed the hint (and initial dojo face, which was vial too) to something that wouldn't be shadowed (i.e., v, laiv, etc.). This did not resolve the issue.

[joemfb]

This is crashing in the jet dashboard.

This fast hint is not valid and is ignored by the jet dashboard:

~%  %vial.100  %vial  ~

This one is valid, and tries to register %one against whatever is in the current subject, as a parent core.

~%  %one  +  ~

Commenting out the first line means that the subject is whatever the file was built against (presumably zuse). Adding back in the first line then matches that existing registration, and attempts to check the current subject against it (as a core). The crash in the jet dashboard is taking the head of 0.

[joemfb]

The jet dashboard needs to be updated to be resilient against bad inputs. I still need to figure out where is best to add additional checks/no-ops. But it should be noted this example has an invalid in it. And, in general, it's impossible to prevent weird things from happening with stateful jet registrations while playing around with hints like this.