fix: handle UTF-16 diagnostic columns

On line 348, the code checks end.character > source_line.encode_utf16().count() as u64 before computing length. However, end.character is a UTF-16 code unit offset (start of a character that is exactly one or two code units). If the reported character offset falls inside a surrogate pair (i.e., points to the second code unit of a 4-byte character like 😀, which is U+1F600, encoded as surrogate pair 0xD83D 0xDE00), then the inequality end.character > count might be false (it's still ≤ count), but the subsequent formatting logic that builds an underline sequence of '~' characters will still use this offset and produce either a misaligned or a truncated marker. This is a correctness bug for diagnostics that point into the second half of a surrogate pair (unlikely but possible if the runtime/TSC reports such internal positions). The earlier boundary check next_utf16 > column_utf16 already returns None in source_line_prefix, so the start side is safe, but the end side length computation does not guard against this case.

The same source_line_prefix function is defined in both cli/tsc/diagnostics.rs (line 18) and runtime/fmt_errors.rs (line 126) with identical implementations. This duplication violates DRY and increases maintenance burden — any future fix or enhancement must be applied in two places, and they can easily drift apart. Consider extracting it into a shared module accessible to both crates.