fix: Change LeaveStreamOpen default from true to false

[puk06]

As of v0.21, the library is documented to close wrapped streams by default. However, the ReaderOptions.LeaveStreamOpen property defaulted to true, which contradicted the documented behavior and caused file locks when deleting archives after extraction.

Changes:

• Set LeaveStreamOpen = false as the default (consistent with v0.21 design)
• Updated ReaderOptions.cs with comprehensive documentation explaining:
  • File-based vs caller-provided stream handling
  • When to use LeaveStreamOpen = true
  • Usage examples for both scenarios
• Updated AGENTS.md Stream Handling Rules section with:
  • Clear explanation of default disposal behavior
  • Overload differences (file-based vs stream-based)
  • Guidance on using ForExternalStream preset

This ensures the implementation matches the documented behavior and prevents unexpected file locking issues during archive deletion.

Fixes: File deletion failures after archive extraction

---

Please note that while this change aligns with the documented specification, it is a breaking change that may affect existing code.
The removal of the explicit LeaveStreamOpen=false override in ZipArchive was motivated by the fact that false is now the default. However, since other Archive types originally relied on the default value of true, existing code that does not explicitly specify ReaderOptions may behave differently than before.
Breaking changes of this nature should be documented somewhere. That said, since I'm not familiar enough with where exactly the documentation should be updated, I've opted not to include those changes in this pull request.

[puk06]

Please note that while this change aligns with the documented specification, it is a breaking change that may affect existing code.
The removal of the explicit LeaveStreamOpen=false override in ZipArchive was motivated by the fact that false is now the default. However, since other Archive types originally relied on the default value of true, existing code that does not explicitly specify ReaderOptions may behave differently than before.
Breaking changes of this nature should be documented somewhere. That said, since I'm not familiar enough with where exactly the documentation should be updated, I've opted not to include those changes in this pull request.