docs(apps-yaml): document write-time log/debug redaction and redact_strings (#4770)

The #4770 write-time redaction and the redact_strings/redact_strings_labelled denylist keys had
no documentation anywhere - the shipped apps.yaml template didn't mention them and
docs/apps-yaml.md's "Storing secrets" section, the natural home for this, stopped at the
existing !secret/key-name-substring coverage.

Added a "Redaction in logs and debug files" subsection covering where redaction applies and
that it happens at write time (predbat.log included, not just downloads), plus a
redact_strings/redact_strings_labelled subsection with examples - leading with the labelled
form since it's the more generally useful shape, per feedback while reviewing this.

Added both settings, commented out, to the shipped apps.yaml template, in the same style as the
file's other end-of-file cross-cutting settings (watch_list) - so a user encountering the need
for this finds it in the file they already have open, not only in the docs site.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: chalfontchubby

apps/predbat/config/apps.yaml

@@ -632,3 +632,15 @@ pred_bat:
   #  - '+[car_charging_planned]'
   #  - '+[car_charging_soc]'
   #  - '{car_charging_now}'
+
+  # Redact additional values from predbat.log and debug dumps that Predbat cannot otherwise
+  # recognise as sensitive (an MPAN or similar identifier surfaced by a third-party HA
+  # integration's sensor, say) - see "Redaction in logs and debug files" in apps-yaml.md.
+  # redact_strings_labelled is a name -> value mapping, masked with your own label (e.g. <my_mpan>
+  # below); redact_strings is a bare list for when you don't need one, masked generically as
+  # <redact_strings>. As with any other setting, either can reference a value in secrets.yaml
+  # with !secret instead of writing it here directly.
+  #redact_strings_labelled:
+  #  my_mpan: "1234567890123"
+  #redact_strings:
+  #  - "1234567890123"

docs/apps-yaml.md

@@ -236,6 +236,32 @@ If a secret is referenced in `apps.yaml` but not found in `secrets.yaml`, Predba
 - All secrets stored in one centralized location
 - Compatible with Home Assistant's secrets system
 
+### Redaction in logs and debug files
+
+Credential values - whether stored in `secrets.yaml` and referenced with `!secret`, or written directly in `apps.yaml` - are masked wherever Predbat writes them out: `predbat.log`, a `predbat_debug_*.yaml` file, and the apps.yaml downloads on the [web interface](web-interface.md). This happens at the point each line is written, not only when a file is later downloaded, so the on-disk files themselves never carry the plaintext value - including if you copy `predbat.log` directly off a Samba share rather than downloading it through Predbat.
+
+A masked value appears with a label naming which credential it was, e.g. `<octopus_api_key>`, rather than a generic placeholder, so a log line stays useful for diagnosing a problem without ever showing the value itself.
+
+#### redact_strings and redact_strings_labelled
+
+Predbat can only recognise a value as a credential by its `apps.yaml` key name (`_key`, `password`, `secret`, `token`) or from the list of account/meter/serial-number-style identifiers it knows about internally. It has no way to know that a value coming from a third-party Home Assistant integration - an MPAN embedded in a sensor's `entity_id` or attributes, say - is sensitive. For anything like that, list the value yourself, preferably with `redact_strings_labelled` - a name -> value mapping, so the masked line reads with your own label instead of a generic one:
+
+```yaml
+pred_bat:
+  redact_strings_labelled:
+    my_mpan: "1234567890123"  # e.g. an MPAN surfaced by a third-party integration
+```
+
+That masks as `<my_mpan>` wherever it appears. If you don't need a label, `redact_strings` is a bare list instead:
+
+```yaml
+pred_bat:
+  redact_strings:
+    - "1234567890123"
+```
+
+Each entry there is masked generically as `<redact_strings>`. As with any other credential, you can reference a `!secret` here too rather than writing the value inline. Both settings are themselves masked wholesale if they ever appear in a debug dump, so the denylist doesn't leak the very values (or, for the labelled form, the label names) it exists to hide.
+
 ## Basics
 
 Basic configuration items