Context

Part of #667. Derived from the 2026-06-13 analysis. monitoring is UNTAGGED (highest v0.1.0), so the remap carries zero SemVer cost if it lands before the v1.0 tag.

Problem

include/kcenon/monitoring/core/error_codes.h defines monitoring_error_code as POSITIVE (enum class : std::uint32_t, collection 1000-1999, storage 2000-2999, config 3000-3999, system 4000-7999+). core/result_types.h:62-63 funnels these straight into common's error_info.code via static_cast<int>. common's classifier (error_codes.h:460-461) reports any code >= 0 as "Success", so every monitoring error is silently classified as success. common reserves -300..-399 for monitoring.

Scope note

This is an underlying-type change (uint32 -> common's signed int) + full re-number + a static_cast call-site sweep (~568 sites, e.g. src/alert/alert_manager.cpp:28-90), not a value shift. Confirm -300..-399 (100 slots) is wide enough for the 7-category set, or introduce a mapping function in to_common_error().

Acceptance Criteria

• monitoring codes map into common's reserved -300..-399 (signed)
• to_common_error() never yields a Success-classified code from a real error (test)
• Call-site sweep complete; build green
• Lands BEFORE the monitoring v1.0.0 tag (Prepare monitoring_system for v1.0 release #667)
• pacs-side regression: injecting a monitoring error surfaces as FAILURE at the apex