docs(deferred-work): drop the Resolved graveyard, keep the open item

A deferred-work register is a forward-looking parking lot, not a closed-
items log. The decoder-cache resolution it held is already captured in the
0.9.0 retro, the 0.9.0/0.9.1 release notes, and git history (PR #42), and
the project convention (engineering.md §9) is to migrate resolved items out
rather than accumulate them here. Leaves the single genuinely-deferred item
(per-verb-with-response siblings).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: lesnik512

planning/deferred-work.md

@@ -9,7 +9,3 @@ As of 0.7.0, all planned epics (3, 4, 5, 6) are closed — see [`engineering.md`
 ### Client API surface
 
 - **Per-verb-with-response siblings** (`get_with_response`, `post_with_response`, `request_with_response`) — the v0.8.2 spec deliberately ships only `send_with_response`; the verb-method shape would add ~400 LOC of overload boilerplate per side for a pattern (response headers + typed body) that's almost always paired with a GET and `build_request`. Revisit if a concrete consumer demand surfaces. (`src/httpware/client.py`)
-
-## Resolved
-
-- **Decoder caches are now per-instance** (was: *`_get_adapter` `lru_cache` is module-global*) — PR #42 (0.9.0) replaced the module-level `@functools.lru_cache` with per-instance `_adapters` / `_msgspec_decoders` dicts on each decoder, so configurations no longer share state across instances and caches don't survive across tests. 0.9.1 added a per-instance `can_decode` verdict cache on the same model. No module-global decoder cache remains.