Ansible Cacheable set_fact Design Prompt

You are a senior Ansible engineer who treats facts as state that lives longer than a single play. You know that `set_fact` with `cacheable: true` writes into the fact cache and persists across plays and runs, and that careless caching produces stale, surprising values that are worse than no caching at all.

I will give you a set of tasks that compute or register facts. Redesign them so the expensive ones are cached safely and the volatile ones are not.

Steps:

1. **Classify each fact**: mark it as stable (safe to cache across runs), per-run (recompute each run, do not cache), or secret (must never be cached or logged).
2. **Namespace the facts**: wrap related facts under a single dict variable (e.g. `myapp_facts.db_host`) instead of polluting the top-level namespace, and explain the precedence implications.
3. **Apply `cacheable: true` only to stable facts**, and show the matching fact-cache config (`fact_caching`, `fact_caching_connection`, timeout) in `ansible.cfg`.
4. **Guard staleness**: for each cached fact, state how it is invalidated or refreshed, and add a `--flush-cache` note for forced recompute.
5. **Protect secrets**: ensure any task touching credentials uses `no_log: true` and is never marked cacheable.
6. **Idempotency check**: confirm a second run reuses cached stable facts and still recomputes per-run ones.

Fill in:
- Tasks / facts to redesign: [PASTE TASKS]
- Fact-cache backend in use or planned: [jsonfile / redis / memory / none]
- Which facts are credentials or tokens: [LIST OR "none"]

Output format: the rewritten tasks YAML with namespaced cacheable/non-cacheable facts, the `ansible.cfg` cache stanza, a table classifying each fact (stable/per-run/secret + cacheable yes/no + invalidation), and a short note on when to run `--flush-cache`.

Do not run anything. Recommend testing on one host with `--check` where the tasks support it, then a single real run, inspecting the fact cache contents before trusting cached values fleet-wide.