cover PCRF Result-Code reject on the UE bearer resource path

[next-nf]

Covers the PCRF-rejection path of the UE-requested bearer resource modification
procedure end-to-end. Until now it was verified only by code-reading: #22
Increments 2/3 had to substitute an unknown-filter trigger, which fails
synchronously in the procedure's first lift and never issues a CCR-Update, so
ccr_result({fail, RC}) and the post-await br_err route had never run in a test.

Test-only — no production change. The path already works.

GH #50 is obsolete. It reported the reject e2e as blocked by
smf_aaa_gx:fold_cca/5 crashing on the static mock's undefined State_at_send.
The async-invoke restack deleted that whole first-step diameter bridge —
fold_cca, ccr_update_issue, ccr_initial_issue and State_at_send are absent
from the tree. Under pipeline_async the entire real pipeline runs in the worker,
so the answer is handled by smf_aaa_static's ordinary synchronous
handle_response/5, whose Result-Code >= 3000 clause returns {fail, Code};
run_pipeline/6 short-circuits on it and returns it verbatim to ccr_result/1.

What's here

• 'Update-Gx-Reject' mock answer carrying DIAMETER_UNABLE_TO_COMPLY (5012).
  A real PCRF refusing a UE resource modification's traffic mapping would answer
  Experimental-Result-Code DIAMETER_ERROR_TRAFFIC_MAPPING_INFO_REJECTED (5144)
  (TS 29.212 §5.5.3), but smf_aaa_static discriminates on the base Result-Code
  AVP only — putting 5144 there would bake a wire-incorrect answer into the fixture.
• ue_delete_packet_filters_pcrf_reject: valid filter ids (so the CCR-Update is
  actually issued and the procedure parks), asserting the Bearer Resource Failure
  Indication (Cause/LBI/PTI), that no Delete or Update Bearer Request follows, and
  that the dedicated bearer is untouched — the short-circuit happens before
  async_m:modify_data, so nothing is committed.
• Refreshed ue_delete_packet_filters_reject's doc string, which described the
  now-deleted foundation defect. Both cases stay: one covers the pre-async guard,
  the other the post-await route.

Verification

pgw_SUITE 134/134, 0 failures. The new case was also mutation-checked: pointing
it at the benign 'Update-Gx' answer makes it fail on the failure-indication
?match, so it is not vacuously passing.

Side note on #51: this is the first test in which an error callback runs after
the procedure went async, so delete_session succeeding at the end is live
evidence that br_err's {next_state, ...} drains async_pending and leaves the
coarse gate open — the property #51 warns is missing on the shared
handle_ctx_error/4 route. It does not fix #51.

Stacked on #57. Merge bottom-up: #45 → #46 → #48 → #56 → #57 → this.