refactor(cursor-rules): reorganize rules into logical directory structure

Restructure .cursor/rules from flat organization to hierarchical categories:
- app/: application-specific rules (timesafari, architectural decisions)
- database/: database-related rules (absurd-sql, legacy dexie)
- development/: development workflow rules
- docs/: documentation standards and markdown rules
- features/: feature-specific implementation rules (camera)
- workflow/: version control and workflow rules

Add base_context.mdc for shared context across all rule categories.
Improves maintainability and discoverability of cursor rules.

.cursor/rules/workflow/version_control.mdc

@@ -0,0 +1,122 @@
+---
+alwaysApply: true
+---
+# Directive: Peaceful Co-Existence with Developers
+
+## 1) Version-Control Ownership
+
+* **MUST NOT** run `git add`, `git commit`, or any write action.
+* **MUST** leave staging/committing to the developer.
+
+## 2) Source of Truth for Commit Text
+
+* **MUST** derive messages **only** from:
+
+  * files **staged** for commit (primary), and
+  * files **awaiting staging** (context).
+* **MUST** use the **diffs** to inform content.
+* **MUST NOT** invent changes or imply work not present in diffs.
+
+## 3) Mandatory Preview Flow
+
+* **ALWAYS** present, before any real commit:
+
+  * file list + brief per-file notes,
+  * a **draft commit message** (copy-paste ready),
+  * nothing auto-applied.
+
+---
+
+# Commit Message Format (Normative)
+
+## A. Subject Line (required)
+
+```
+<type>(<scope>)<!>: <summary>
+```
+
+* **type** (lowercase, Conventional Commits): `feat|fix|refactor|perf|docs|test|build|chore|ci|revert`
+* **scope**: optional module/package/area (e.g., `api`, `ui/login`, `db`)
+* **!**: include when a breaking change is introduced
+* **summary**: imperative mood, ≤ 72 chars, no trailing period
+
+**Examples**
+
+* `fix(api): handle null token in refresh path`
+* `feat(ui/login)!: require OTP after 3 failed attempts`
+
+## B. Body (optional, when it adds non-obvious value)
+
+* One blank line after subject.
+* Wrap at \~72 chars.
+* Explain **what** and **why**, not line-by-line “how”.
+* Include brief notes like tests passing or TS/lint issues resolved **only if material**.
+
+**Body checklist**
+
+* [ ] Problem/symptom being addressed
+* [ ] High-level approach or rationale
+* [ ] Risks, tradeoffs, or follow-ups (if any)
+
+## C. Footer (optional)
+
+* Issue refs: `Closes #123`, `Refs #456`
+* Breaking change (alternative to `!`):
+  `BREAKING CHANGE: <impact + migration note>`
+* Authors: `Co-authored-by: Name <email>`
+* Security: `CVE-XXXX-YYYY: <short note>` (if applicable)
+
+---
+
+## Content Guidance
+
+### Include (when relevant)
+
+* Specific fixes/features delivered
+* Symptoms/problems fixed
+* Brief note that tests passed or TS/lint errors resolved
+
+### Avoid
+
+* Vague: *improved, enhanced, better*
+* Trivialities: tiny docs, one-liners, pure lint cleanups (separate, focused commits if needed)
+* Redundancy: generic blurbs repeated across files
+* Multi-purpose dumps: keep commits **narrow and focused**
+* Long explanations that good inline code comments already cover
+
+**Guiding Principle:** Let code and inline docs speak. Use commits to highlight what isn’t obvious.
+
+---
+
+# Copy-Paste Templates
+
+## Minimal (no body)
+
+```text
+<type>(<scope>): <summary>
+```
+
+## Standard (with body & footer)
+
+```text
+<type>(<scope>)<!>: <summary>
+
+<why-this-change?>
+<what-it-does?>
+<risks-or-follow-ups?>
+
+Closes #<id>
+BREAKING CHANGE: <impact + migration>
+Co-authored-by: <Name> <email>
+```
+
+---
+
+# Assistant Output Checklist (before showing the draft)
+
+* [ ] List changed files + 1–2 line notes per file
+* [ ] Provide **one** focused draft message (subject/body/footer)
+* [ ] Subject ≤ 72 chars, imperative mood, correct `type(scope)!` syntax
+* [ ] Body only if it adds non-obvious value
+* [ ] No invented changes; aligns strictly with diffs
+* [ ] Render as a single copy-paste block for the developer