[WIP] Conduct deep bug audit for Mediabox-UnityClient

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>Deep bug audit — file-by-file scan</issue_title>
<issue_description>## Task: Deep, file-by-file bug audit of Mediabox-UnityClient

This issue is intended to be picked up by an automated coding agent. Use whatever model the runtime has selected — do not refuse the task because of model preference. Do your best work with what you have.

The goal of this audit is quality over speed within the time budget. A small list of carefully verified, real bugs is far more valuable than a long list of false positives.

Time budget — IMPORTANT

You have approximately 50 minutes of wall-clock time before the runtime kills your session. Plan accordingly:

• Do NOT refuse the task because you think you can't finish. Start work immediately.
• Front-load the most valuable files (source code in the primary language, security-sensitive areas, build/config). Save assets and low-value files for last.
• After roughly 40 minutes of work, stop discovering new bugs and start writing audit.md. Commit and push before the 50-minute mark.
• If you cannot review every file, that is acceptable. Be honest in audit.md about what you didn't get to, under a section called "Files NOT yet reviewed (out of time)".
• A partial audit that is committed and pushed is infinitely more useful than a perfect audit that never lands.

---

Deliverable

1. Create a new branch off the repository's default branch named:
   copilot/bugscan-<YYYY-MM-DD>
   (The copilot/ prefix is required — branch creation will fail otherwise.)
2. Add a single file audit.md at the repo root.
3. Commit the file to the branch and push it.
4. If a pull request is opened (or auto-created by the agent runtime), it MUST be a draft PR. Do not mark it "ready for review". Preferably do not open a PR at all — just push the branch.
5. Post a short comment on this issue with the branch name and a one-paragraph summary of the most critical findings.

audit.md format

# Bug Audit — Mediabox-UnityClient — <date>

Files reviewed: <N>
Files skipped (with reason): <N>
Files NOT yet reviewed (out of time): <N>

## Critical
### [C-01] <Short title>
- **File(s):** `path/to/file.ext:123`
- **Category:** memory safety / concurrency / crypto / auth / data loss / logic / API misuse / config / ...
- **Description:** What the bug is, in concrete terms. Quote the relevant code.
- **Impact:** What can go wrong in production. Be specific (crash, data corruption, auth bypass, leaked key, money loss, …).
- **Reproduction / reasoning:** Why this is a real bug, not a stylistic concern. Trace the call path if relevant.
- **Suggested fix:** Concrete, minimal change.
- **Confidence:** high / medium

## High
…
## Medium
…
## Low
…

## Files reviewed
<bullet list of all reviewed file paths>

## Files intentionally skipped
<bullet list with reason: generated, binary, third-party fork, asset, certificate, lockfile, …>

## Files NOT yet reviewed (out of time)
<bullet list — leave empty if all in-scope files were reviewed>

Sort findings within each severity by descending impact.

---

How to do the work — methodology

1. Enumerate every file in the repo. Build the full list before starting.
2. Classify and filter. Skip only:
   • generated files (mocks marked generated, build artifacts, lockfiles like package-lock.json / Gemfile.lock / Package.resolved, minified bundles, transpiler output)
   • binary blobs (images, fonts, certificates, audio, video, model files) — but record where they're consumed
   • vendored third-party code that is byte-identical to upstream
     Everything else is in scope, including: source files in every language present, build configs (Makefile, *.gradle, *.pbxproj, Dockerfile, *.tf, *.yml CI workflows), JSON config/manifest/asset data, shell scripts, fastlane files, env templates.
3. Spawn parallel Task subagents. Each subagent receives at most 8 files and audits them in depth. Use general-purpose subagents and run them concurrently in batches. Track which files have been dispatched in a small in-memory ledger so nothing is dropped and nothing is double-audited. If a subagent reports it ran out of time or context, re-dispatch the missed files to a fresh subagent if budget allows, otherwise list the missed files under "Files NOT yet reviewed".
4. Each subagent must:
   • Read every line of every file it was assigned. No skimming.
   • For each suspected bug, trace it across the codebase (call sites, related types) before reporting it, to rule out false positives.
   • Return findings in the exact severity format above, plus the list of files reviewed.
5. Aggregate subagent results into the single audit.md. Deduplicate. Re-sort by severity then impact.
6. Self-review pass. Before committing, re-read audit.md end-to-end and remove anything that is:
   • a style/lint nit
   • a "could be improved" suggestion without a concrete bug
   • speculative ("might be a race if …") unless you can name the conditions
     The bar is: if a senior engineer would say "that's not a bug", remove it.

Severity rubric (use exactly these)

• Critical — exploitable security issue, data loss/corruption, guaranteed crash on a common path, auth bypass, leaked secret, payment/IAP bug that costs money, RCE, SSRF, SQL injection.
• High — crash on a less common but realistic path, data race that can corrupt state, memory leak that grows unbounded, broken retry/error handling that hides failures, incorrect cryptography usage, missing TLS validation, IDOR, missing authz checks.
• Medium — wrong behavior on edge cases (empty input, network failure, backgrounding, locale, timezone), resource leaks bounded in size, deprecated/unsafe APIs with a real downside, logic bugs in non-critical features.
• Low — narrow correctness issue with limited user impact, off-by-one in non-critical UI, log-only issues, minor accessibility correctness problems.

What to look for (general — apply whatever fits this repo's stack)

• Concurrency: races, missing locks, awaiting on the wrong queue/thread, @MainActor violations, async/await misuse, unhandled promise rejections, callback hell with lost errors.
• Memory: retain cycles, unbounded caches/arrays, large allocations on hot paths, missing observer/listener removal, leaked timers/subscriptions.
• Error handling: swallowed exceptions, generic catch (_) {}, try! / !! / unwrap() on values that can fail, missing rollback after partial failure.
• Input validation: trusting user input, path traversal, command injection, SQL/NoSQL injection, XSS, prototype pollution, regex DoS, deserialization of untrusted data.
• Auth / crypto: missing authz checks, broken token validation, hardcoded secrets, weak algorithms (MD5/SHA1 for security, ECB mode), non-constant-time comparisons, missing TLS validation, certificate pinning bypasses.
• Data: off-by-one, integer overflow, float comparisons, locale-sensitive sorts/parses, timezone bugs, encoding mismatches.
• Networking: missing timeouts, no retry/backoff or unbounded retry, missing cancellation, response parsing that crashes on unexpected shape.
• Config / build: secrets in source, debug flags shipped in release, disabled hardening (ASLR, stack canaries, -O0), permissive CORS / CSP, world-writable files.
• Platform-specific: for mobile — lifecycle re-entrancy, background task handling, IAP/StoreKit/Billing receipt validation; for web — CSRF, XSS, open redirects; for Terraform — public S3 buckets, missing encryption, overly broad IAM; for CI YAML — pull_request_target misuse, secret exposure in logs, untrusted action versions.

Scope boundaries

• Repo only — do not audit submodules unless the file is committed in this repo.
• No external network calls during the audit.
• Don't run the tests / don't build. Static analysis + manual reasoning only.

Reporting back

Post a comment on this issue when done with:

• Branch name
• Total bugs by severity (e.g., Critical: 2, High: 5, Medium: 9, Low: 14)
• Whether the audit was complete or partial (with file counts)
• The top 3 findings, one line each

If you encounter blockers (auth issues, missing tool, the repo turns out to be empty or pure binary, etc.), comment on this issue describing the blocker rather than guessing.
</issue_description>

Comments on the Issue (you are @copilot in this section)