Should the value of `error` be mutable?

### Example
In `perfect-numbers` we have this test case:
https://github.com/exercism/problem-specifications/blob/8df6cb2ed8e77aa3ac0c02744cd9ddb83920f5f2/exercises/perfect-numbers/canonical-data.json#L121-L130

And we notice (see https://github.com/exercism/problem-specifications/pull/1691) that we would like to make this change:
```diff
{
"uuid": "72445cee-660c-4d75-8506-6c40089dc302",
- "description": "Zero is rejected (not a natural number)",
+ "description": "Zero is rejected (not a positive integer)",
"property": "classify",
"input": {
"number": 0
},
"expected": {
- "error": "Classification is only possible for natural numbers."
+ "error": "Classification is only possible for positive integers."
}
```

We seem to have decided that `description` is allowed to mutate when the "meaning is unchanged" (that is, we do not add a `reimplements` test case for e.g. a simple `description`-only typo fix).

The question is: should the contents of an `error` also be considered mutable when the "meaning is unchanged", or should that require a new test case?

### Discussion
My initial opinion is something like:
1. We said that `description` should be mutable if we don't change the "meaning" of the test.
1. There are some useful error-message changes that don't change the "meaning" of the test either, and the value of `error` is similar to the "description" of the error. In the limiting case, it seems messy to add a new test case just to fix a typo in an `error` value.
1. Therefore, directly mutating the `error` value should similarly be allowed when the "meaning is unchanged".

Drawbacks:
- Is there a track that asserts something about the contents of the error message for this kind of test? Such a track would have to update that assertion, even though their `tests.toml` didn't change.
- The CI check for immutability would need to check that `expected` doesn't change, but make a special case for an `error`-only change.