[marma-dev]

Problem

Log Forward Service can render ETW FILETIME timestamps with embedded U+000E formatting markers. The host decoder attempts time.Time unmarshalling before identifying the ETW source, rejects these records, and stops normal consumption of the guest log stream.

Change

• Identify the source before decoding the standard timestamp.
• Remove only U+000E markers from ETW timestamps before passing them to the existing strict time.Time JSON decoder.
• Preserve ordinary GCS log behavior, event payloads, timestamp precision, and errors for other invalid timestamps.
• Add timestamp regression cases and a concatenated-stream test proving subsequent records are consumed.

This PR is based directly on main and is independent of the sidecar ETW feature in #1. It does not change policy, guest binaries, or Log Forward Service.

Validation

• Confirmed new marked-timestamp and stream-continuation tests fail without the fix.
• Full internal/vm/vmutils test suite passed.
• go vet ./internal/vm/vmutils passed.
• Host shim and uvmboot builds passed.
• CI-pinned golangci-lint v2.11.0 using Go 1.26.8 reported zero issues.
• Live C-WCOW VBS UVM with Secure Boot enabled and the private Rego-enabled sidecar from Add policy-gated ETW logging for sidecar GCS #1: 2 sidecar events parsed with nanosecond-accurate vm.time, plus 169 subsequent ETW events; zero timestamp read errors.
• Runtime-logging-denied run: zero sidecar events, 77 other ETW events, zero timestamp read errors.

Remaining unrelated test-harness limitation

Forced UVM teardown truncated a final unrelated ETW record, producing the existing gcs terminated diagnostic. The pre-existing launcher output-processing teardown hang also requires closing the launcher after the UVM exits. Neither issue is changed by this timestamp fix.