Closes: #XXXX
Refs: #2799

Description

#2799 added a new q-like quoter named qp, for "quote passable", that renders any value into Justin source text. This was specifically motivated for displaying patterns within error messages in a readable and informative manner.

The @endo/patterns package itself formulates many error messages to explain why a specimen did not match a pattern. Some of these message include quoted forms of nested patterns. But those were still quotes with q, leading @dckc to report still seeing error messages like

Error {
    message: '... - Must match one of ["[match:splitRecord]","[match:splitRecord]"]',
  }

This PR changes the quoting of nested errors to use qp instead, so a [match:splitRecord] might instead render as

`makeTagged("match:splitRecord", [
  {
    assetKind: makeTagged("match:or", [
      "nat",
      "set",
      "copySet",
      "copyBag",
    ]),
    decimalPlaces: makeTagged("match:and", [
      makeTagged("match:gte", -100),
      makeTagged("match:lte", 100),
    ]),
  },
])`

This is more verbose. But error messages are designed to carry the critical clues to help find a bug. For nested patterns, this extra information is worth the verbosity.

Security Considerations

We were already quoting nested patterns with q, unredacting them, under the assumption that specimens may carry secrets worth protecting from callers, but patterns typically do not. Switching these from q to qp is consistent with that assumption, but actually exposes info that q happened not to expose. When unredacting happened not to expose secrets it said were ok to expose, it is easy for developers not to notice the secrets that could have been shown but weren't. After this PR, these unredacted secrets will be exposed to callers.

Scaling Considerations

Where q is lazy, qp is eager, rendering its argument up front into Justin even if the containing error is never created or thrown. Thus, we must take care to only use qp when we're already committed to creating and throwing the error. I believe all such changes in this PR do so, and so do not add overhead to the happy path.

Documentation Considerations

I don't know what documentation we provide explaining the interpretation of error messages. If we have any explain pattern match error messages, this PR might need us to change those explanations.

Testing Considerations

Using qp to formulate the error messages definitely makes it more awkward to test is the error message is as expected. You can see this in the tests this PR needed to change. Fortunately, as shown in these error message tests, you can use ${q(qp(...))} to formulate the golden in the test.

Compatibility Considerations

Because this PR changes the error messages, as pointed out above, golden tests of error message text may no longer match, causing old working tests to start failing. However, this is not technically a compat break, because we take the stance that the content of error messages is not normative, so the error messages can become more informative over time with a version bump. Thus, I use : rather than ! to recommend that this PR not cause a version bump. (See #2868 (review) below)

Upgrade Considerations

None.