ci: guard against silently merge-corrupted lockfiles

[amal66]

What happened on #233

The backend CI job on #233 failed at npm ci with:

The npm ci command can only install with an existing package-lock.json …

The lockfile did exist. The real cause: a Merge branch 'main' commit on the PR branch auto-merged backend/package.json and backend/package-lock.json — both modified on each side — and git's line-level text merge spliced the two versions into syntactically invalid JSON without raising a conflict:

• package.json lost the comma after the branch's new "test:stack" script, right where main's "test:coverage" line was merged in.
• package-lock.json lost the two closing-brace lines of the supertest/cookie-signature entry, where both sides had inserted different package entries at the same alphabetical position.

npm (Arborist) swallows the lockfile parse error and treats the file as absent, hence the misleading "no existing package-lock.json" message. Since git saw no conflict, GitHub showed the branch as cleanly mergeable — nothing looked wrong until npm tried to read the file. (The immediate breakage is fixed on the #233 branch itself; this PR is the prevention.)

Prevention (this PR)

1. .gitattributes: merge=binary for package-lock.json and bun.lock. Generated files shouldn't be text-merged. With the binary driver, any concurrent change surfaces as an explicit conflict, and the documented resolution is to regenerate (git checkout origin/main -- package-lock.json && npm install) instead of hand-merging.
2. CI parse-check before npm ci in both backend and frontend jobs: JSON.parse on package.json and package-lock.json. If corruption ever lands anyway, CI fails in one second with the actual reason instead of npm's misleading usage error.

Habits that keep this away

• After merging main into a PR branch that touches dependencies, regenerate the lockfile rather than trusting the merge result, and re-run npm ci locally.
• Treat any lockfile diff a merge produced as suspect — it's generated output; only npm install should write it.

Verified: node -e "JSON.parse(...)" passes on both files at main; the workflow change is additive and job-local, so it's safe on trees with or without the other pending test PRs.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

QA Runner seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}