Harden your store: headers, limits, admin safety and a review

You are a careful senior application security engineer working inside my project folder. The store is "Thread & Needle", a fashion e-commerce store selling women's and men's clothing, shoes and accessories in United States at threadandneedle.com, with payments through Stripe. Harden it and review it. I am not a programmer, so explain any technical word in a few words and tell me what each change protects against.

Plan first: inspect the whole project, then show me a numbered plan with the risks you found and wait for my OK before changing anything. Work on a new branch and use small commits.

Tasks:
1. Security headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and frame protection. Allow only what the store really uses (my own domain, Cloudinary images, Stripe's hosted pages and scripts if any). Start the Content-Security-Policy in report-only mode, test every page, then enforce it. Read the documentation of the Next.js version installed in this project before writing config, because file names and APIs differ between versions.
2. Rate limiting for login, sign-up, password reset, contact forms, checkout start and admin routes. Serverless hosting does not share memory between requests, so do not rely on a simple in-memory counter in production. Explain the options (a database table, or a free hosted store, or the host's firewall) and ask me which to use.
3. Input validation: confirm every route handler and server action validates with Zod, limits lengths and sizes, and escapes output. Look for raw SQL strings and unsafe HTML rendering.
4. Sessions and CSRF: check Auth.js cookie settings (httpOnly, secure, sameSite), session lifetime, password hashing, safe redirects after login, and that webhooks verify signatures and are the only routes outside normal request protection.
5. Admin protection: server-side role checks everywhere, no default or shared admin password, a rate limit and clear lockout message, and optional two-step login for admins with a standard authenticator app, including recovery codes stored hashed.
6. Secrets: scan the working files and the full git history with a secret scanner such as gitleaks, confirm .env.local is git-ignored, and confirm .env.example has names only. If a secret was ever committed, tell me to rotate it; do not just delete it.
7. Dependencies: run npm audit, fix what is safe, and list what needs my decision. Do not run forced upgrades without asking.
8. Backups: add a documented script for a local database dump and a tested restore into a scratch database. Explain what the online database provider offers for backups and restore, and tell me to verify it on their pricing page.
9. Logging: use structured logs with redaction so passwords, tokens, emails, addresses and payment details never appear.
10. OWASP Top 10 review: go through each category for this project and write SECURITY_REVIEW.md with status (fixed, ok, needs decision), evidence and the file involved. Be honest about limits; this is not a substitute for a professional penetration test.

Security rules for you: never print, log or commit a secret, and ask me for any key you need.

Verify: run type-check, lint, tests and a production build, then show me the response headers of the home page, a blocked rapid-login attempt, and the secret scan result.

Report back in this format: 1) What was done. 2) What I should check myself. 3) Anything that needs my decision.

Review the prompt, then copy it. Never paste real passwords or API keys into a chat.