What

Reconcile the network_system release contract across CMake, vcpkg metadata, README, CHANGELOG, and v1.0 documentation.

Part of kcenon/common_system#684 and #964.

Current read-only analysis observed:

Why

Consumers cannot tell whether network_system is still pre-1.0 or already governed by the v1.0 public API contract. That matters because pacs_system depends on this package and release automation / vcpkg constraints derive behavior from package metadata, not only README text.

Where

• CMakeLists.txt
• vcpkg.json
• CHANGELOG.md
• README.md
• docs/v1.0-api-surface.md
• vcpkg overlay port metadata, if maintained outside this repository

How

Approach

1. Audit the latest tag/release state and decide the intended truth: still pre-1.0 candidate, or ready to publish as v1.0.0.
2. If still pre-1.0, soften README/CHANGELOG wording so it clearly says "candidate / pending tag" and points to Prepare network_system for v1.0 release #964.
3. If ready for v1.0.0, bump CMake and package metadata together and prepare the vcpkg overlay update.
4. Update downstream notes for pacs_system dependency pinning.
5. Post the final decision and evidence back to [EPIC] Ecosystem hardening follow-up from 2026-05-21 analysis common_system#684.

Acceptance Criteria

• CMakeLists.txt, vcpkg.json, README, and CHANGELOG agree on the same version state
• The README states whether v1.0 is released or still pending, with no contradictory language
• vcpkg overlay metadata is aligned with the chosen version state
• Prepare network_system for v1.0 release #964 is updated with the version/package decision
• [EPIC] Ecosystem hardening follow-up from 2026-05-21 analysis common_system#684 receives the final matrix row for network_system

Verification

• cmake --preset vcpkg configures with the chosen version metadata
• vcpkg install kcenon-network-system or the repository's equivalent overlay consume test succeeds