Implement Security changes

[naveedious]

Summary

Security hardening from a review of the build and supply chain. No app logic
changes. Reproducible builds, pinned CI, and secret scanning, plus a fix to the
stale compose file.

What changed

Reproducible dependency builds

• Commit package-lock.json (was gitignored) and remove it from .gitignore.
• Dockerfile now runs npm ci instead of npm install, so builds install the
  exact pinned tree and fail if the lockfile and package.json drift.

Pin GitHub Actions to commit SHAs

• actions/checkout, docker/login-action, docker/build-push-action,
  aquasecurity/trivy-action, and actions/delete-package-versions are pinned
  to full commit SHAs with the version kept as a trailing comment.
• A mutable tag can be repointed if a maintainer account is compromised, which
  would run attacker code in a job that holds packages: write and the
  GITHUB_TOKEN. Pinning removes that path.

Secret scanning (gitleaks)

• Add .gitleaks.toml: extends the default ruleset and adds rules for media
  API keys (Tautulli, Sonarr, Jellyfin), SECRET_KEY, and OIDC client secrets.
  The allowlist covers .env.example, package-lock.json integrity hashes,
  documented placeholders, and ${VAR} compose interpolation.
• Add .github/workflows/gitleaks.yml: scans on push and pull request with full
  history, and fails the build on a leak. Pinned to a commit SHA.
• README gets a short Security section documenting the local and CI scan.

docker-compose cleanup

• Drop WEB_USERNAME and WEB_PASSWORD, which the app no longer reads.
• Add the required SECRET_KEY. Without it the container exits on startup, so
  the committed compose file would not have run as written.

Testing

• npm ci --omit=dev resolves cleanly against the new lockfile (0 advisories).
• Ran gitleaks 8.21.2 against this branch:
  • working tree: no leaks
  • full git history: no leaks
  • control test with planted fake keys: all three rules fired and failed as
    expected
• Action SHAs were resolved from the upstream tags with git ls-remote.

Not included

The webhook endpoint is still open by default (no secret required when
webhook_secret is blank). That is a deliberate design choice for the LAN
deployment and is left for a separate discussion.