Polish batch: close() implies flush(), discovery version semantics, handle uniqueness docs, putAttachment return shape

[cuibonobo]

From docs/design-review-2026-08.md §B6 — small independent items, batched like #69 was.

• close() should imply flush() (or the docs should say when flush() alone is meaningful). The quick start requires both in order; today Stack.close() only calls adapter.close?.(), and correctness silently depends on each adapter's close being flush-inclusive. Making Stack.close() call flush() first is the common file-like-API expectation.
• Discovery "version": "1.0" has no defined semantics — no negotiation rule, no compatibility statement. Before a server ships with it, decide what a client should do with it (refuse on major mismatch?) or drop it until it means something.
• handle fields claim "short unique identifier" (_entity, _group) but nothing enforces or indexes uniqueness. Fine — but the doc comments should say "uniqueness by convention, not enforced" so app authors don't build lookup logic on a guarantee that isn't there.
• putAttachment() returns only the fileId while POST /attachments returns the full _attachment@1 record; a caller wanting their metadata record's id (e.g. to set a filename later) must query for it. Returning the record (or { fileId, record }) matches the wire shape — worth deciding before the signature is load-bearing for external apps, since it's a breaking change to StackClient.

Cross-refs: design-review-2026-08 §B6.