Restore docstring coverage and enforce it with ruff's pydocstyle rules

[laughingman7743]

Use case

#601 (August 2025) added comprehensive Google-style docstrings to the public API. Nothing enforces docstrings, and coverage has drifted since then. It is also uneven: whole groups of methods and properties have none, and a few docstrings no longer match their signatures.

Measured on master at a86a180, pyathena/ only (tests excluded):

Kind	Total	Without a docstring
Public functions and methods	432	232
Properties (getters and setters)	388	360
Private functions and methods (_name)	307	158
Dunder methods	154	116

ruff's pydocstyle rules (--select D, Google convention) report:

• D102 (public method) 547
• D107 (__init__) 66
• D100 (module) 63
• D105 (magic method) 43
• D104 (package) 15
• D101 (public class) 4
• D417 (argument missing from Args:) 3
• D415 (first-line punctuation) 3

The D102 count includes properties.

Files with the most undocumented public and private functions:

File	Count
sqlalchemy/compiler.py	81 (mostly visit_* overrides)
filesystem/s3.py	35
filesystem/s3_async.py	33
sqlalchemy/array.py	26
sqlalchemy/base.py	26
aio/sqlalchemy/base.py	21
common.py	19
formatter.py	18

Properties are concentrated in model.py, result_set.py, and filesystem/s3_object.py.

Proposed change

1. Decide the policy per kind:
   • Public API: required.
   • Properties: a one-line docstring.
   • Overrides of SQLAlchemy (visit_*), fsspec, and DB API methods: document only where PyAthena's behavior differs from the parent, and otherwise exempt them, for example with typing.override and ruff's ignore-decorators.
   • Private helpers: follow the existing contributor convention (Google style for touched functions); ruff does not check them.
2. Fill the gaps, public API first, and fix the D417/D415 findings.
3. Enforce with ruff: D rules with convention = "google" for pyathena/. Start from per-file ignores that match the current state, then remove them as files are completed, so new code cannot add more gaps.
4. Tests are out of scope, unless the maintainer wants the same policy there.

This can land in several PRs, for example by package.

Validation plan (if implementing)

• just lint passes with the new D rules.
• just docs build renders the API reference without new warnings.
• Documentation-only changes need no AWS tests.