Fix post-close docs and a dangling README reference

The cursor close() change that preserves rowcount/lastrowid (matching
stdlib) left several docs stale: the sync and async close() method
docstrings and a README bullet still said close() scrubs rowcount /
lastrowid, and the _ExecuteManyAccumulator.apply() comment still listed
_rowcount among the cleared fields. Correct all of them to state close()
clears only the result-set surface (description / rows) and preserves
rowcount / lastrowid; description remains the one documented divergence
from stdlib. Also drop a dangling internal issues/ path that should not
ship in the README.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: antoineleclair

README.md

@@ -188,10 +188,11 @@ borrowed from one.
   the prior INSERT's rowid sticky across executemany. The driver
   diverges deliberately (which row's rowid is "the" rowid for a batch
   of N inserts is ambiguous).
-- **`Cursor.close()` scrubs `description` / `lastrowid` / `_rows`.**
-  stdlib preserves `description` and `lastrowid` post-close; dqlite
-  scrubs to `None` to enforce the closed-cursor "no operation
-  performed" surface.
+- **`Cursor.close()` clears `description` / `_rows` but preserves
+  `rowcount` / `lastrowid`.** Matches stdlib for `rowcount`/`lastrowid`
+  (both readable post-close); diverges only on `description`, which
+  stdlib leaves populated whereas dqlite returns `None` (a closed
+  cursor has no fetchable result set to describe).
 - **`Cursor.lastrowid` returns `None` after a fresh CREATE TABLE.**
   stdlib `sqlite3` returns `0` for a never-INSERTed cursor; dqlite
   returns `None`. After the first INSERT/REPLACE both drivers agree
@@ -217,9 +218,8 @@ borrowed from one.
   ``check_same_thread=False`` opt-in behaviour. Default
   ``check_same_thread=True`` enforces strict per-thread; methods
   called from a foreign thread on a default-mode Connection raise
-  ``ProgrammingError``. Tier 3 (cursor sharing) is tracked as
-  future work in
-  ``issues/dbapi-threadsafety-tier-3-cursor-sharing-stdlib-parity.md``.
+  ``ProgrammingError``. Tier 3 (sharing a single cursor across threads)
+  is not supported.
 - **No `executescript` / `create_function` / `create_aggregate` /
   `create_window_function` / `iterdump` / `backup` / `set_authorizer`
   / `serialize` / `blobopen`.** stdlib-specific APIs that have no

src/dqlitedbapi/aio/cursor.py

@@ -1318,10 +1318,11 @@ def close(self) -> None:
         immediate ``NotSupportedError`` rather than a discarded
         coroutine).
 
-        Scrubs ``description`` / ``rowcount`` / ``lastrowid`` /
-        ``_rows`` / ``_row_index`` symmetrically with the sync sibling
-        ``Cursor.close`` (see that docstring for the full
-        "post-close state" rationale).
+        Clears the result-set surface ``description`` / ``_rows`` /
+        ``_row_index`` but PRESERVES ``rowcount`` / ``lastrowid``
+        (readable after close, matching stdlib ``sqlite3.Cursor``),
+        symmetrically with the sync sibling ``Cursor.close`` (see that
+        docstring for the full "post-close state" rationale).
 
         **``arraysize`` is deliberately NOT scrubbed**: it is a
         caller-set configuration *hint* (PEP 249 §6.1.2 default ``1``;

src/dqlitedbapi/cursor.py

@@ -1202,11 +1202,11 @@ def apply(self, cursor: _ExecuteManyCursor) -> None:
         otherwise.
 
         No-op if the cursor has been closed concurrently — the async
-        ``close()`` contract scrubs ``_rows``/``_description``/
-        ``_rowcount``, and re-populating those fields here would
-        visibly un-close the result set for any attribute-level
-        caller. Sync flavour is immune via the outer threading lock;
-        this guard pins the async flavour. The per-iteration guard in
+        ``close()`` contract clears ``_rows``/``_description``, and
+        re-populating those fields here would visibly un-close the
+        result set for any attribute-level caller. Sync flavour is
+        immune via the outer threading lock; this guard pins the async
+        flavour. The per-iteration guard in
         async ``executemany`` catches the racy close between iterations;
         this guard catches a close that lands after the loop exits
         but before ``apply()`` writes state back.
@@ -2715,20 +2715,19 @@ def close(self) -> None:
         thread-check ``ProgrammingError``. Matches stdlib
         ``sqlite3.Cursor.close`` — close is always safe to call.
 
-        **Divergence from stdlib sqlite3 on post-close attribute
-        state**: this implementation scrubs ``description`` /
-        ``rowcount`` / ``lastrowid`` / ``_rows`` / ``_row_index``
-        for a consistent "no operation performed" surface (per
-        the project rationale: avoid stale-state reads on a closed
-        cursor). Stdlib ``sqlite3.Cursor.close()`` leaves
-        ``description`` populated (the last query's tuple-of-7-tuples)
-        and leaves ``lastrowid`` at its prior value; only ``rowcount``
-        is reset to ``-1`` there. Cross-driver code that introspects
-        ``cur.description`` AFTER ``close()`` (e.g. relying on
-        context-manager exit to close before reading metadata) sees
-        ``None`` here vs the populated tuple on stdlib. PEP 249 is
-        silent on post-close attribute state; the scrub-for-consistency
-        choice is deliberate and documented.
+        **Post-close attribute state**: ``close()`` clears the
+        result-set surface — ``description`` / ``_rows`` /
+        ``_row_index`` — because a closed cursor cannot serve a result
+        set, but PRESERVES ``rowcount`` and ``lastrowid``, matching
+        stdlib ``sqlite3.Cursor``, which leaves both readable after
+        ``close()``. Reading ``cur.lastrowid`` / ``cur.rowcount`` after
+        ``close()`` returns the last operation's values — load-bearing
+        for consumers such as SQLAlchemy's Result layer, which closes
+        the cursor and then reads ``cursor.lastrowid`` lazily.
+        ``description`` is the one divergence: stdlib leaves the last
+        query's tuple-of-7-tuples populated, whereas this driver returns
+        ``None`` post-close (a closed cursor has no fetchable result set
+        to describe). PEP 249 is silent on post-close attribute state.
 
         **``arraysize`` is deliberately NOT scrubbed**: it is a
         caller-set configuration *hint* (PEP 249 §6.1.2 default ``1``;