Remove dependency maintenance boilerplate from README

Author: KSemenenko

AGENTS.md

@@ -409,7 +409,7 @@ For changes outside existing owner authorization, obtain direction before changi
 ### Dislikes
 - Repeated permission questions for already authorized work.
 - Working `*.plan.md`, `*.brainstorm.md` and `*.acceptance.md` files MUST NOT be created or committed anywhere in this checkout. Remove existing copies and ignore these patterns without exceptions. Keep durable requirements, acceptance criteria and execution/verification contracts in the owning `docs/Features/` specification and required ADR; agent working notes stay outside the repository. This explicit owner correction on 2026-10-03 supersedes every root/local instruction requiring separate planning files without weakening feature, test, architecture or qualification requirements.
-- The root README MUST NOT accumulate CI run histories, test counts, internal implementation receipts, governance procedures, or package/version dumps. Keep a concise honest development-status statement and link to the canonical status and qualification records instead (owner correction 2026-10-03).
+- The root README MUST NOT accumulate CI run histories, test counts, internal implementation receipts, governance procedures, dependency-maintenance instructions, generic dependency-license boilerplate, or package/version dumps. Credits MUST name the projects actually used and explain their contribution. Keep a concise honest development-status statement and link to the canonical status and qualification records instead (repeated owner correction 2026-10-03).
 - GitHub Actions MUST expose exactly three plainly named workflows: CI combines build and ordinary project tests for PR/push/manual checks; Benchmarks runs all load/comparison suites, produces complete authenticated measurements and then qualifies/publishes the website; Release builds the solution, real database images/distribution and packages, then creates a GitHub Release and immutable version tag. Do not split Tests or Website into additional workflows (explicit owner correction 2026-10-03 supersedes the earlier five-workflow layout).
 - Release tags MUST be `v<major>.<minor>.<yyMMdd>.<daily-build>`: major/minor are configured in source, the third component is the UTC date and the fourth starts at 1 each day and increases without tag reuse or overwrite. Build/package/image/manifest identities MUST agree; reruns recover their original reservation. Release automation is authorized to create the corresponding Git tag, GitHub Release and versioned database image/package assets; preserve protections and qualification gates (owner direction 2026-10-03).
 - KeyLoad product release packaging and publication are deferred until the owner explicitly requests a release or confirms product readiness. Keep Release prepared and manual; do not dispatch package/image builds, create release tags or publish releases merely to prove this workflow while the product is unfinished (owner correction 2026-10-03).

README.md

@@ -117,8 +117,6 @@ KeyLoad is developed by [Managed Code](https://www.managed-code.com/) and builds
 
 Development and presentation also use [Aspire](https://github.com/dotnet/aspire) for Docker orchestration, [TUnit](https://github.com/thomhurst/TUnit) for tests, [BenchmarkDotNet](https://github.com/dotnet/BenchmarkDotNet) for microbenchmarks, and [Three.js](https://github.com/mrdoob/three.js) for the website's cluster illustration.
 
-Dependency versions are maintained in [Directory.Packages.props](Directory.Packages.props). Each dependency retains its own license.
-
 ## License
 
 KeyLoad is licensed under [MIT](LICENSE).