Make the privacy note and credits match the code

Make the privacy note and the credits for this app say exactly what the code does, no more and no less, in as few words as the facts allow.

App (its path, and one line on what it is): {{app}}
Current privacy note, credits and claims (the files or pages that hold them, or "none yet"): {{current_copy}}
Facts not in the repo (live provider and tier, log retention, host dashboard features, contact address), or "none": {{deployment_facts}}

Work from the code, not from the current copy, the README or what apps like this usually do. Read the browser code, server code, build config, HTML head, stylesheets, security headers, environment and deployment config, and the built output if there is one.

1. Inventory. One row per data flow, each with the file and line that proves it.
- Sent out: every request the browser or the server makes to another host: AI providers, ad networks, analytics, fonts, maps and tiles, search or suggestion APIs, bot checks, error reporting, CDNs, embeds. Say what triggers it (page load, each keystroke, submit), exactly which fields go (text typed, earlier context, a user's own key) and on whose account (the app's, or the user's own key). Loading a font, script or image from another host sends that host the visitor's IP address and browser details: that is a row too. For a user's own API key, say where it is stored, every server it passes through, and whether any log or error report can capture it.
- Through links: any link, redirect, form or share button that carries user input to another site, and what the Referer carries under the page's Referrer-Policy.
- In the browser: every localStorage, sessionStorage and IndexedDB key, every Cache Storage cache a service worker fills, and every cookie, even a small flag, with what it holds and when it is cleared.
- On the server: databases, key-value stores and caches. What is kept, keyed by what (per user, or shared so one person's result can be served to another), and for how long: quote the TTL. If a cached result is served to other people, check the cache key includes everything that changes its credit or licence (for example, which licensed source was used), so nobody gets a result carrying another result's attribution.
- Logged: what the app's own logs write, what the host's request logs hold (URLs with query strings, IP addresses), and what rate limiters and abuse checks keep. Check every limiter: one that keys on the raw address for a minute still uses the raw address. A hashed address is a pseudonym, not anonymous.
- Decided by config: anything an environment variable or deployment setting switches (which AI provider, free or paid tier, a feature flag). Record every case, not just the default.
- Every path: follow the fallback, error, retry and cache-hit paths as well as the normal one (no source found, a source or provider unreachable, the user's own key). Give a path its own row when what it sends, keeps or credits differs.
Where a fact I gave fills a row, cite "owner" as its evidence. If neither the code nor those facts can tell you something (a provider's own retention, an owner's decision), write "unknown" and add it to the questions. Never fill a gap from memory.

2. Credits and notices, from the same reading.
- Every package that ships to the browser, with its licence. Build-only tools don't count; code that a pre-bundled package inlines, and helpers the bundler injects, do. For a dual-licensed package, say which licence you use. If the build can generate this list, make it do so.
- Content, data, maps, images and fonts the app shows, each with its licence and the attribution wording it requires.
- Generated content is credited to AI, naming the provider this deployment uses, so nobody takes it for a person's work, and says AI can be wrong.
- Trademarks the copy names, with their owners, and a not-affiliated line. Scope the app's own copyright to what it owns.

3. Mismatches. Check every sentence of the current copy against the inventory: privacy note, credits, footers, README, help text under inputs, onboarding dialogs, tooltips, error and fallback messages, meta tags (description, copyright, og) and aria-labels. Mark each one true, false, overclaims, missing, stale or unknown, and cite the row. Treat absolutes as false until a row proves them: "never", "only", "nothing", "every", "all", "anonymous", "no tracking", "stays in your browser", "no limits". When the copy makes a promise worth keeping and the code breaks it, propose a code fix instead of weakening the copy, and say which you chose.

4. Rewrite: the same facts in fewer words.
- The privacy note is a short list, one line per heading: In your browser, Sent out, Advertising, AI providers, Abuse checks, Hosting and logs, Caching, Contact, Last updated. Each line says what, to whom and for how long. Drop a heading that has no rows.
- Link each third party's policy or terms instead of paraphrasing them.
- Keep every disclosure a provider's terms require, even where it costs words: an ad network's cookie, opt-out and consent wording, a bot check's privacy notice, age limits, and whether a free tier (including a user's own unbilled key) may use what is sent for training. Cite the term that requires it.
- A fact that depends on config is rendered from the same config the code reads, or states every case.
- Where text goes to a third party as the user types, say so beside the input and link the privacy note from there. Check every link to the note lands on it.
- Credits: one or two short sentences per section, keeping every attribution a licence requires.
- Add nothing the code or those terms don't back: no legal bases, certifications or rights procedures unless the owner confirms them. Put those in the questions.

5. Review marker.
- Put a comment at the top of the privacy note's source, in that file's comment syntax, starting with the token "privacy-review". It says what to check, so whoever finds it can do the review without this prompt, and ends "then delete this comment". Check it doesn't show as text on the shipped page; if the build prints or escapes comments, strip it in the build.
- Add a step to the build or CI that already runs on every push. It searches only the privacy note's file for the token (a repo-wide search finds the check itself) and prints a warning, not a failure, naming the file and what to do. It also warns when that file is missing. Print the warning where people look: in GitHub Actions, a `::warning file=<path>,line=1::` annotation. Search the file that ships if it ships as written (a static HTML page); otherwise search the source.
- Don't delete the marker yourself. A person deletes it after checking, and the warning stops.

Write the privacy note, credits, copy fixes, marker and CI step into the repo. List the code fixes and wait for my go-ahead before making them.

Reply under these headings, in this order, keeping every one (write "none" under an empty one):
- Inventory: a table (what, where it goes or is kept, trigger, how long, evidence)
- Mismatches
- Privacy note, in full
- Credits, in full
- Code fixes, not yet applied
- Marker and CI step
- Open questions for the owner

Show all 50 lines