regex_remap treats regex resource errors as non-matches when routing

A regex resource error in `regex_remap` is logged but does not stop rule evaluation. The plugin continues to later rules, so an exhausted match can produce a successful redirect to a different destination. If no later rule matches, the plugin returns `TSREMAP_NO_REMAP`.

Bryan Call pointed out this separate behavior while reviewing #13652. That PR fixes the overly low matching-work limit described in #13651. The proposed JIT-stack change was withdrawn from that PR after review; resource exhaustion remains possible and its handling needs a separate decision.

### Current behavior

The [error branch](https://github.com/apache/trafficserver/blob/390bafd7683d14de7faee45129a122557456c092/plugins/regex_remap/regex_remap.cc#L1171) increments the failure count and logs any negative result other than `PCRE2_ERROR_NOMATCH`, then continues the loop. It does not distinguish a failed evaluation from a genuine non-match when deciding whether to try the next rule.

The regression test in #13652 demonstrated this with these rules:

```text
^/cms(\?.*)TOKEN(.*)$ https://redirect.example/cms$1TOKEN$2 @status=302
^/cms.*$ https://fallback.example/ @status=307
```

Before the matching-work fix, `/cms?partner=TOKEN&x=` followed by 2,000 `a` characters exhausted the first rule's work limit (`-47`). ATS then returned the fallback 307 rather than the intended 302. This was verified in an end-to-end AuTest. The limit fix makes that particular input succeed, but does not change the error branch.

### Desired behavior

Define and test an explicit policy for match-work, depth, heap, and JIT-stack exhaustion. A matching error should not automatically be treated as a non-match and redirect to an unrelated fallback destination. Returning a visible transaction error is one possible policy; compatibility with configurations that currently rely on fallthrough needs consideration.

The follow-up should cover both a later fallback rule and the case where no later rule matches. The current diagnostic logging should remain useful even if transaction handling changes.

Start in plugins/regex_remap/regex_remap.cc around the error branch at line 1171, then review the regression AuTest described in #13652. Define and document a policy for match-work, depth, heap, and JIT-stack exhaustion, preserving useful diagnostics. Add coverage for both a later fallback rule and the case where no later rule matches, and verify the chosen transaction result.

Written by the indexing model from the issue text.