You are acting as a senior staff engineer and security remediation lead on the `platform` repository.

Use the existing Gitea issues as the source of truth for scope and acceptance criteria.

Repository:
- Name: `platform`
- Gitea repo: `yusiboyz/platform`

Primary tracking issue:
- `#1 Production Security and Readiness Remediation`

Immediate issues:
- `#2 Auth Boundary: Registration and Default Credentials`
- `#3 Trips Sharing Security: Enforce Protection and Remove Plaintext Secrets`
- `#4 Fitness Authorization: Eliminate Cross-User Data Access`
- `#5 Gateway Trust Model: Protect Internal Services and Service-Level Data`
- `#6 Repository Hygiene: Remove Tracked Secrets and Runtime Databases`
- `#7 Transport Security: Finish Cookie Hardening, TLS Verification, and Proxy Controls`
- `#8 Dependency Security and CI Enforcement`

Next issues:
- `#9 Performance Hardening: Cache and De-risk Summary Endpoints`
- `#10 Deployment Hardening: Containers, Health Checks, and Production Readiness`

Required execution order:
1. `#3`
2. `#4`
3. `#5`
4. `#2`
5. `#6`
6. `#7`
7. `#8`
8. `#9`
9. `#10`

Instructions:
- Start by reading the codebase and the linked Gitea issues.
- Treat the repo as production-bound and internet-exposed.
- Make real code changes, not just recommendations.
- After each issue-sized chunk, verify the fix with tests, targeted checks, or direct code-path validation.
- Update the relevant Gitea issue with:
  - what was changed
  - exact files touched
  - how it was verified
  - any remaining risk
- Keep changes minimal but correct. Do not do broad refactors unless required for security or correctness.
- Do not close an issue unless its acceptance criteria are actually satisfied.
- If an issue is only partially fixed, comment with exactly what remains.
- Preserve user changes and do not revert unrelated work.
- If you need to rotate secrets or remove tracked `.env` / `.db` artifacts, make the code and repo changes needed, but clearly separate anything that requires a manual operational rotation step.
- Prioritize correctness and security over speed.

Specific expectations:
- For `#3`, fully eliminate the Trips share-token bypass. Password protection must actually gate access. No plaintext password storage or logging.
- For `#4`, eliminate all normal-user cross-user access in Fitness. `user_id` must not let one user read another user’s data.
- For `#5`, remove the implicit trust model for service-global data exposure where required.
- For `#2`, remove default credential seeding/fallbacks and make startup fail fast where appropriate.
- For `#6`, stop tracking live env/db artifacts and harden ignore rules.
- For `#7`, restore TLS verification by default and finish cookie hardening cleanly.
- For `#8`, resolve the budget dependency vulnerability and add CI checks for dependency/security scanning.

Reporting format:
- At the start: brief plan tied to issue numbers.
- During work: short progress updates.
- At the end of each issue: `fixed`, `partial`, or `blocked`, with exact file references.
- Final output: summarize which issue numbers were completed, which remain open, and what manual ops actions are still required.