fix: synchronize v4.5.0 release history into development

[andrewzolotukhin]

Synchronize master's v4.5.0 release history into development so release PR #248 can merge cleanly. Development had not received the three master-only release commits, leaving older package metadata beside the newer v5 implementation.

• Resolve the server manifest conflict with internal auth, di and schema ranges at ^4.5.0, retaining development's @fastify/busboy ^3.2.2 and ws ^8.22.0.
• Restore the released versions and changelog entries for the 19 packages already published at v4.5.0. Remove the two changesets consumed by that release; retain every pending v5 changeset and the three new packages' existing versions.
• Regenerate the lockfile with targeted npm workspace updates. Only 19 workspace entries change; all external dependency entries, including the recent security fix, are unchanged.

The diff contains 41 release-metadata files: 19 manifests, 19 changelogs, the two consumed changeset deletions and package-lock.json. Library source, public exports, engines, licensing, external dependency ranges and archived API documentation are unchanged.

Merge this PR using GitHub's “Create a merge commit” option to carry master's release ancestry into development. After that, PR #248 can merge into master without this conflict. Final v5 versioning remains with the existing Changesets release workflow.

Validation:

• Clean npm ci, npm run lint, npm run build, npm run test and npm audit --audit-level=high passed. Tests: 293 files / 5,303 tests, no type errors.
• All workspace versions and internal dependency metadata agree with the lockfile.
• Read-only Changesets status still plans v5.0.0 for all 22 published packages.
• SHA-256 checks confirm all 9,134 archived documentation files are unchanged.
• Master is an ancestor of this branch; git merge-tree with master completed without conflicts.

GitHub Actions run 37931308967 passed for commit bf3ebe6f1c6b529ed26f26224f7a8e1ddd1a1cd9. All four jobs succeeded, including coverage floors, dependency security, packed-package smoke tests, both website builds, API reference generation and PostgreSQL/S3/demo E2E integration checks. No new published-package behavior is introduced, so no additional changeset is required.