v0.3.1: The QoS cap hardened under a real load

The QoS cap holds up under a real load: qos_cap.yml caps only when it
tightens, changes nothing when run twice, and a lift leaves the volume as
the cap found it, limit or none; the telemetry source counts a lift's
normal polls from the cap; the pod guards render the array's message for
a missing pod. Verified against the two Purity//FA 6.10.6 arrays and
Ansible Automation Platform 2.7: the cap under a fio load through its
Slack approval, the platform's job-failure notification, and both
supported-base images running on the platform;
docs/VERIFICATION.md has the ledger.

• The pod guards of dr_promote.yml, dr_demote.yml and
  dr_switchover.yml report the array's message for a missing pod ("Pod
  does not exist.") instead of an undefined-variable error: the message's
  default branch is evaluated even when the read returned an error, so the
  fields it names now tolerate absence; a unit test renders every guard
  message for a missing pod.
• Verified (VERIFICATION.md): the platform's Slack notification on a job
  failure, from a switchover launched against a pod that does not exist;
  the QoS cap under a real fio load from the platform host over iSCSI,
  twice through the day-2 route with its approval from Slack, on a volume
  with its own 1000-IOPS limit (recorded, enforced at 500, restored) and on
  one without (lifted to no limit, not the maximum); the two supported-base
  ansible-builder images running on the platform, the execution environment
  under a notify job and a guarded switchover job and the decision
  environment under the alertmanager activation taking an alert through its
  rule to a job.
• A lifted cap leaves the volume without a limit again: qos_cap.yml
  removes the limit through the API with an empty string, because
  purefa_volume sends the 100000000 maximum for iops_qos: 0, which
  reads back as a limit (100M in the GUI); a real previous limit is still
  restored through the module (HARDWARE_NOTES.md). The collection's
  master now clears a limit properly (QosPatch, 1.47.0); the API path
  stays until a release carries it.
• The lift's "normal for qos_lift_normal_polls polls" counts from the cap:
  the telemetry signal resets a volume's normal-poll counter when it
  becomes capped, so a cap requested through the day-2 route on a volume
  whose latency was already normal lasts those polls instead of being
  lifted at the next one (seen live: lifted after 34 seconds, "normal for
  10 polls").
• qos_cap.yml is idempotent: a cap on a volume that already carries the
  qos_cap tag and a lift on a volume without it change nothing. Live, two
  lift jobs ran 19 seconds apart; the second found the tags gone and
  cleared the limit the first had just restored.
• qos_cap.yml never loosens a limit: when the volume's own IOPS limit is
  already at or below cap_iops the cap run writes the tags and leaves the
  limit alone, so a lift restores the same value; applied_iops reports
  the limit in force. A unit test renders the condition and the artifact.
• The undo-demote refusal is the purefa_pod module's, not the array's:
  the array allows a second demotion and adds another undo-demote pod.
  everpure.flasharray's master now carries an eradicate_undo option on
  the module (1.47.0) that eradicates them inside the demote; the
  switchover's own step stays until a release carries it.