feat(tests): Add comprehensive tests for SSR admin vendors module

Add 8 BDD-style tests for the vendors module covering grid/list
operations and vendor merge functionality. Tests follow established
patterns from accounts_test.clj and include proper database
verification.

Tests Implemented:
- vendor-grid-loads-with-empty-database
- vendor-fetch-ids-returns-correct-structure
- vendor-fetch-page-returns-vendors
- vendor-hydrate-results-works
- vendor-merge-transfers-references
- vendor-merge-same-vendor-rejected
- vendor-merge-invalid-vendor-handled
- vendor-hydration-includes-all-fields

Key Implementation Details:
- Uses setup-test-data helper with unique temp IDs
- Tests focus on public interface (fetch-page, merge-submit)
- Follows BDD Given/When/Then pattern
- All 8 tests passing (26 assertions)

Documentation:
- Created implementation plan in docs/plans/
- Documented solution patterns in docs/solutions/
- Created code review todos for future improvements

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

todos/011-pending-p3-add-assertion-messages.md

@@ -0,0 +1,137 @@
+---
+status: pending
+priority: p3
+issue_id: "011"
+tags: [testing, readability, agents, vendors, assertions]
+dependencies: []
+---
+
+# Add Assertion Messages to Improve Agent-Readable Test Output
+
+## Problem Statement
+
+Most assertions in vendors_test.clj lack custom messages, making failures hard for automated agents to interpret and debug. Adding messages would:
+- Improve automated failure analysis
+- Make test output self-documenting
+- Help future developers understand failures
+
+## Findings
+
+**From agent-native-reviewer:**
+
+**Current assertions without messages:**
+```clojure
+(is (seq? vendors))
+(is (number? matching-count))
+(is (= 0 (count vendors)))
+(is (contains? result :ids))
+```
+
+**Better with messages:**
+```clojure
+(is (seq? vendors) "Expected vendors to be a sequence")
+(is (number? matching-count) "Expected matching-count to be a number, got: %s" (type matching-count))
+(is (= 0 (count vendors)) "Expected empty vendor list when database is empty, found %d vendors" (count vendors))
+```
+
+**Benefits:**
+- Agents can understand what went wrong without reading code
+- Self-documenting test output
+- Easier debugging when tests fail
+
+## Proposed Solutions
+
+### Option A: Add Messages to All Assertions (Recommended)
+**Effort:** Small (20 minutes)
+**Risk:** Low
+
+Add descriptive messages to all `is` assertions:
+```clojure
+;; Before:
+(is (= 200 (:status result)))
+
+;; After:
+(is (= 200 (:status result))
+    "Expected 200 status, got %d" (:status result))
+```
+
+**Pros:**
+- Maximum clarity for agents and humans
+- Self-documenting failures
+
+**Cons:**
+- Adds verbosity
+- More code to maintain
+
+### Option B: Add Messages to Complex Assertions Only
+**Effort:** Small (10 minutes)
+**Risk:** Low
+
+Only add messages to non-obvious assertions:
+```clojure
+;; Keep simple assertions as-is:
+(is (= 200 (:status result)))
+
+;; Add messages to complex ones:
+(is (>= (:count result) 3)
+    "Expected at least 3 vendors (2 new + 1 from setup), got %d"
+    (:count result))
+```
+
+**Pros:**
+- Less verbose
+- Focus on non-obvious assertions
+
+**Cons:**
+- Inconsistent coverage
+- Agents still can't understand simple failures
+
+## Recommended Action
+
+**Go with Option B** - add messages to complex/value-checking assertions first. This provides the most value with less overhead.
+
+Priority assertions to enhance:
+1. Lines 53, 64: Magic number assertions with `>=`
+2. Lines 110, 117: Status code and count assertions
+3. Lines 176-177: Field value assertions
+
+## Technical Details
+
+**High-Priority Assertions:**
+- Line 53: `(is (>= (:count result) 3))`
+- Line 64: `(is (>= matching-count 3))`
+- Line 110: `(is (= 200 (:status result)))`
+- Line 117: `(is (= 0 (count remaining-sources)))`
+
+**Message format:**
+```clojure
+(is assertion "Expected X, got Y: %s" value)
+```
+
+**Verification:**
+```bash
+lein test auto-ap.ssr.admin.vendors-test  # Test failure messages
+```
+
+## Acceptance Criteria
+
+- [ ] Complex assertions have descriptive messages
+- [ ] Messages explain expected vs actual values
+- [ ] Tests still pass
+- [ ] Code formatted with lein cljfmt
+
+## Work Log
+
+### 2026-02-07 - Initial Creation
+
+**By:** Agent-Native Reviewer Agent
+
+**Actions:**
+- Identified lack of assertion messages
+- Documented benefits for automated agents
+- Prioritized which assertions need messages most
+
+**Learnings:**
+- Assertion messages critical for agent-based development
+- Most assertions in file lack messages
+- Focus on complex/value-checking assertions first