ci: add concurrency groups to prevent deployment race conditions (#92)

Without concurrency groups, multiple workflow runs triggered by rapid
successive pushes can overlap. For the merge workflow, a slower build
of an older commit could finish after a newer one, deploying stale code
to mlab-oti. For the PR workflow, redundant builds waste CI minutes.

- Merge workflow: uses github.ref (the main branch) so only the latest
  push to main proceeds to production deployment.

- PR workflow: uses github.head_ref (the PR branch name) with a
  fallback to github.run_id, so only the latest push to a given PR
  branch triggers a preview deployment. cancel-in-progress: true
  cancels any in-flight run when a newer one starts.

Author: Kunal1522

.github/workflows/firebase-hosting-merge.yml

@@ -6,6 +6,10 @@ name: Deploy to Firebase Hosting on merge
   push:
     branches:
       - main
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
 permissions:
   contents: read
   checks: write

.github/workflows/firebase-hosting-pull-request.yml

@@ -3,6 +3,10 @@
 
 name: Deploy to Firebase Hosting on PR
 'on': pull_request
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+  cancel-in-progress: true
 permissions:
   contents: read
   checks: write