chore: Update yarn.lock

[erights]

closes: #XXXX
refs: #1890 (comment)

Description

At #1890 (comment) @kriskowal writes

Nothing you’ve done should have caused the changes to yarn.lock. This suggests that if you ran yarn on master, you’d get the same changes. If that’s the case, it would be fine to submit them in a separate PR. But, for purposes of expedience, it’s fine to include a chore: Update yarn.lock commit. I do recommend a separate commit and to create a merge commit to preserve it when merging this PR.

Indeed, this PR is a result of running yarn on current endo master, and seems to reproduce the same changes. I do not offer my own opinion on whether these changes are correct, and depend fully on my reviewers.

Security Considerations

yarn.lock changes can potentially introduce and/or repair security vulnerabilities. I have no idea if this PR does either or both.

Scaling Considerations

None

Documentation Considerations

Likely none.

Testing Considerations

Likely none.

Upgrade Considerations

Given that these changes surprised @kriskowal , it would be good to understand what changed on master to cause these.

[erights]

The changes in this PR were generated by yarn on master before #1890 was merged into master. After merging and then rebasing this PR on master, yarn does not make any further changes to yarn.lock, validating that these yarn.lock changes are independent of #1890

[mhofman]

it would be good to understand what changed on master to cause these.

Likely some PR that didn't include all related yarn.lock changes (or a rebase gone wrong). I'd recommend endo has a porcelain check like agoric-sdk does.