docs: add admin provider setup task and update project guidelines

- add detailed task spec for /admin/providers UI with webhook integration
- add product sync strategy with manual, webhook, and scheduled sync
- update PROGRESS.md to prioritise admin provider UI as next task
- add writing style guidelines (british english, sentence case, concise)
- add commit guidelines (atomic, imperative, suggest at checkpoints)
- add pragmatic testing guidelines (test boundaries, skip trivial)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

CLAUDE.md

@@ -170,6 +170,52 @@ socket |> assign(form: to_form(changeset))
 - Reference DOM IDs from templates in tests
 - Debug with LazyHTML: `LazyHTML.filter(document, "selector")`
 
+## Writing Style
+
+- Casual, British English tone throughout (code, comments, commits, docs)
+- Sentence case always, never title case ("Admin providers" not "Admin Providers")
+- Brief and tight in prose. Cut fluff. No waffle.
+- Avoid em dashes, semicolons in prose, and overly formal language
+- Don't sound like an LLM wrote it (no "straightforward", "robust", "leverage", "comprehensive")
+- Comments explain why, not what. Skip obvious ones.
+
+**Code style:**
+- Explicit and obvious over clever and terse
+- Readable code that anyone can follow beats "smart" one-liners
+- Stick to idiomatic Phoenix/Elixir/LiveView/Oban patterns
+- Follow conventions from the existing codebase
+- When in doubt, check how Phoenix generators do it
+
+## Commits
+
+- Suggest a commit at logical checkpoints (feature complete, tests passing)
+- Run `mix precommit` before committing
+- Atomic commits with one logical change each
+- Commit messages: imperative mood, lowercase, no full stop
+  - Good: `add provider connection form validation`
+  - Bad: `Added provider connection form validation.`
+
+## Testing
+
+Write tests for new features, but be pragmatic about coverage.
+
+**Do test:**
+- Public context functions (the API boundary)
+- Critical user flows (auth, checkout, sync)
+- Edge cases and error handling
+- Complex business logic
+
+**Skip tests for:**
+- Trivial getters/setters
+- Framework-generated code
+- Pure UI tweaks with no logic
+- Implementation details that may change
+
+**Approach:**
+- Prefer integration tests over isolated unit tests for LiveViews
+- One test file per module, colocated in `test/` mirror of `lib/`
+- Use fixtures from `test/support/fixtures/` for test data
+
 ## Documentation Workflow
 
 **Single source of truth:** [PROGRESS.md](PROGRESS.md)