Implement semantic versioning for frontend and backend

### Overview
The project lacks a formal versioning strategy. Implement semantic versioning (semver) for both the frontend and backend packages to track releases and communicate the impact of changes.

### Current State
- All three `package.json` files (root, backend, client) are at **0.3.0**
- One ancient git tag: `v0.2.0` from February 2020
- No GitHub releases, no CHANGELOG, no release tooling
- ~30% of recent commits follow conventional commit format — inconsistent across contributors
- No commitlint enforcement
- Deploys to AWS ECS via Docker, images tagged by git short SHA, manual `workflow_dispatch`

### Action Items

**Phase 1 — Foundation**
- [ ] Install and configure [changesets](https://github.com/changesets/changesets) (best fit for monorepo, doesn't require conventional commits upfront)
- [ ] Add changeset-bot GitHub Action to prompt contributors for changesets on PRs
- [ ] Unified versioning to start (frontend/backend tightly coupled), split later if needed

**Phase 2 — Commit conventions**
- [ ] Add [commitlint](https://commitlint.js.org/) with `@commitlint/config-conventional`
- [ ] Add commit-msg husky hook to enforce conventional commits
- [ ] Document commit format expectations for contributors

**Phase 3 — Automated releases**
- [ ] GitHub Action to create version PRs from accumulated changesets
- [ ] Auto-generate CHANGELOG per package

**Phase 4 — Deploy integration**
- [ ] Wire semver tags into AWS ECS deploy workflows (replace git SHA tagging)
- [ ] Tag Docker images with semver in addition to SHA

### Resources/Instructions
- https://semver.org
- https://github.com/changesets/changesets
- https://commitlint.js.org
- https://github.com/conventional-changelog/commitlint