fix(btree): enforce BtreeMaxSize limit on fresh inserts with ErrTreeFull

[kael-developer]

Summary

Enforces the existing BtreeMaxSize constant (10,000,000) as a hard upper bound on the number of entries in a B-tree. Previously, the constant was defined but never checked during insert operations, allowing unbounded growth.

Changes

doclite/btree.go

• ErrTreeFull sentinel error: Added a documented, exported var ErrTreeFull that Insert returns when the tree is full.
• Insert method: Restructured the insert logic so the BtreeMaxSize check only applies to fresh inserts (when the pool is empty and NumDocuments >= BtreeMaxSize). Pool-based ID reuse is allowed to proceed even when the tree is at capacity, since reuse doesn't increase NumDocuments or consume additional resources.
• Documentation: Added clear doc comments on Insert explaining the ErrTreeFull return.

doclite/btree_test.go

• TestBtreeMaxSizeEnforced: Rewrote to test the boundary efficiently by setting NumDocuments directly instead of inserting 10 million documents. Tests:
  1. Normal inserts below the limit succeed
  2. Insert at exactly BtreeMaxSize - 1 succeeds
  3. Insert at BtreeMaxSize returns ErrTreeFull with id = -1
  4. NumDocuments is not incremented on failed insert
  5. Pool-based inserts bypass the limit
  6. After pool is exhausted, insert fails with ErrTreeFull again

How to Verify

go build ./...
go test ./doclite/  # All btree tests pass; TestFile failure is pre-existing

Acceptance Criteria Met

• ✅ BtreeMaxSize is enforced as a hard upper bound on entries
• ✅ Check triggers before any new entry is persisted
• ✅ Insert returns a distinct, documented ErrTreeFull error
• ✅ Pool-based reuse is not blocked (doesn't increase resource usage)
• ✅ No changes to BtreeMaxSize value, no runtime configurability added