Add comprehensive tests for QueryCollection error handling edge cases

Relates to: PR #441 ("add error tracking and retry methods to query collection utils")
Scope: Testing / reliability
Breaking changes: None (tests only)

Summary

PR #441 added error tracking methods but several edge cases lack test coverage. This issue proposes comprehensive tests to ensure robust error handling behavior.

Missing Test Coverage

1. clearError() throwing behavior

• clearError() throws when refetch fails
• errorCount increments once per terminal failure (after retries)
• Error state is properly restored when clearError() fails

2. Error count precision

• No double-count on same errorUpdatedAt: multiple observer emissions with identical timestamp do not bump errorCount
• Error count resets to 0 on successful query
• Error count persists across multiple failed retries within same attempt

3. Exact filter targeting (depends on #537)

• Exact filter targeting: sibling queries with shared prefixes are not refetched
• refetch() only affects the specific queryKey, not parent or sibling keys
• clearError() uses exact targeting since it calls refetch()

4. Disabled/unobserved query behavior (depends on #537)

• Disabled/unobserved behavior: with type: 'active', clearError()/refetch() is a no-op and does not throw unless configured otherwise
• Disabled queries don't increment error count when they would normally fail
• Unobserved queries handle error state correctly

5. Recovery state tracking (if implemented in #539)

• isRecovering() (if added) toggles true → false around the retry window
• Recovery state is cleared on both success and failure
• Multiple concurrent clearError() calls handle recovery state correctly

6. Timing and concurrency

• Concurrent clearError() calls don't create race conditions
• Error state consistency during overlapping refetch operations
• Observer updates during error recovery maintain correct state

Test Structure

describe('QueryCollection error handling edge cases', () => {
  describe('clearError() behavior', () => {
    it('throws when refetch fails')
    it('increments errorCount only once per terminal failure') 
    it('restores error state when clearError fails')
  })

  describe('error count precision', () => {
    it('does not double-count on same errorUpdatedAt')
    it('resets to 0 on successful query')
  })

  describe('exact targeting', () => {
    it('does not refetch sibling queries with shared prefixes')
    it('clearError uses exact targeting')
  })

  describe('disabled/unobserved queries', () => {
    it('is no-op with type: active when disabled')
    it('handles unobserved query errors correctly')
  })

  describe('concurrency and timing', () => {
    it('handles concurrent clearError calls')
    it('maintains state consistency during overlapping operations')
  })
})

Acceptance Criteria

• All edge cases listed above have dedicated test coverage
• Tests verify both success and failure scenarios
• Mock queryClient behavior to simulate various error conditions
• Tests are isolated and don't depend on external timing
• Cover both optimistic and reset-on-success timing semantics (if #539 is implemented)

Start by reading the QueryCollection implementation and the related changes in PRs #441, #537, and #539 to understand the existing error, retry, targeting, and recovery behavior. Add isolated tests for the listed failure, recovery, targeting, disabled-query, and concurrency cases, then verify both success and failure semantics without relying on external timing.