Support LiteQueue as a context manager #27

Context

Each LiteQueue now owns one write connection and ten read connections. close() releases all eleven and is idempotent, but the class does not support with LiteQueue(...) as queue:.

The recent constructor changes also create the write connection before validating the existing database schema and stored maxsize. If construction raises at that stage, __init__ does not explicitly close the partially created connection.

Why implement this

Eleven connections make explicit cleanup more important. Context-manager support gives callers a standard, reliable ownership pattern. Constructor cleanup prevents file descriptors and database handles from depending on garbage collection after expected validation errors.

Proposed direction

• Add __enter__() that returns self.
• Add __exit__() that closes all owned connections and returns False so active exceptions propagate.
• Preserve idempotent close() behavior.
• Wrap constructor setup so any failure closes every connection created so far.
• Document that LiteQueue owns all of its SQLite connections.

Acceptance criteria

• with LiteQueue(...) as queue: closes the write connection and full read pool.
• Context-manager exit does not hide exceptions.
• Repeated close() remains safe.
• Constructor validation or schema failures do not leak connections.
• Tests cover normal exit, exceptional exit, repeated close, and partial initialization failure.
• make test passes.