chore: address PR review feedback

- CHANGELOG: reword the 2.2.3 entry to be user-facing (drop stack-auth/CIP-3159 implementation detail), per the project changelog convention. Traceability stays in the commit/PR.
- Trim the vendored crate to library essentials: remove tasks.toml (node build tooling unused by Proxy), the upstream CHANGELOG.md, and Cargo.toml.orig. src/ is kept verbatim from the published stack-auth 0.34.1-alpha.4 plus the single CIP-3159 fix.

Intentionally NOT changed: lint/structure findings inside vendored upstream library code (src/token.rs expect(), src/auto_strategy.rs env-var test isolation, src/device_client.rs 409 handling). These are verbatim third-party code in paths Proxy doesn't exercise; they should be fixed upstream, not diverged in a surgical hotfix vendor.

Author: freshtonic

CHANGELOG.md

@@ -10,7 +10,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Fixed
 
-- **ZeroKMS authentication failures ~15 minutes after startup**: Fixed a token-refresh wedge in the access-key authentication path. When an in-flight request was cancelled at the wrong moment (for example, a client disconnecting mid-query), token refresh could permanently stall, causing `ZeroKMS error: Request not authorized` on all encrypt/decrypt operations roughly 15 minutes (the access-token lifetime) after connecting. Connections worked on startup and then began failing in lockstep. Backports the upstream `stack-auth` token-refresh fix (CIP-3159).
+- **ZeroKMS authentication failures ~15 minutes after startup**: Fixed an issue in the access-key authentication path where, after an in-flight request was interrupted at the wrong moment (for example, a client disconnecting mid-query), access-token renewal could stall. This caused `ZeroKMS error: Request not authorized` on all encrypt/decrypt operations roughly 15 minutes (the access-token lifetime) after connecting — connections worked on startup and then began failing in lockstep.
 
 ## [2.2.2] - 2026-06-01