Support concurrent KVP telemetry with configurable event prefix

[peytonr18]

Summary

Bolsters the KVP telemetry infrastructure to support concurrent KVP emissions from multiple processes/libraries and allows external callers to configure their own event prefix.

Changes

Configurable event prefix (kvp.rs)

• Added event_prefix: String field to EmitKVPLayer so each subscriber instance carries its own prefix.
• Updated generate_event_key to accept event_prefix as a parameter instead of using the module-level constant.
• Updated Kvp::new to accept event_prefix: &str.
• Changed EVENT_PREFIX from const to pub const so it can be re-exported.

Public API (logging.rs)

• Kvp::new(vm_id, event_prefix) now takes Option<&str> for the prefix — None falls back to EVENT_PREFIX, Some("my-lib-1.0") allows a custom prefix.
• Re-exported EVENT_PREFIX as pub use crate::kvp::EVENT_PREFIX for external consumers.
• setup_layers passes EVENT_PREFIX to the internal Kvp::new.

Safe concurrent truncation (kvp.rs)

• truncate_guest_pool_file now acquires an exclusive flock before checking file metadata and truncating, eliminating a TOCTOU race where concurrent processes could both decide the file is stale and truncate each other's data.

Kvp::write_kvps made pub(crate) (kvp.rs)

• Promoted write_kvps from private to pub(crate) so concurrent tests (and future internal callers) can use it directly without the full tracing infrastructure.
• Changed encode_kvp_item visibility from private to pub(crate).

Concurrent write tests (kvp.rs)

• test_multi_thread_kvp_concurrent_writes: 4 threads × 5,000 iterations each, each with its own file descriptor, writing to the same temp file. Verifies all 20,000 records are intact and decodable.
• test_multi_process_kvp_concurrent_writes: 4 child processes × 5,000 iterations each writing to the same temp file. Verifies all 20,000 records are intact and decodable.

Resolves #239

[cadejacobson]

This looks awesome to me! Good work

[cjp256]

I wonder if kvp::new() should be responsible for opening the file as we're already opening it there?

Seems like having the interface dictate initialization avoids allowing the caller to do unexpected things when opening the file.