Keep the new comments ASCII, like the rest of the crate

Two horizontal-ellipsis characters in comments this branch added, in a file whose merge-base has no
non-ASCII byte anywhere. `...` says the same thing and does not depend on the reader's terminal or
the diff viewer's encoding.

Found by scanning for non-ASCII rather than by reading, which is the only way this class shows up:
it does not fail a build, `typos` does not flag it, and a diff renders it as an ordinary character.
The same scan found 53 em dashes and a stray CJK character on the sibling PR.

Author: awsmadi

guard/tests/utils.rs

@@ -109,7 +109,7 @@ pub fn get_full_path_for_resource_file(path: &str) -> String {
 /// there, because `get_full_path_for_resource_file` builds them from it.
 ///
 /// This replaced a `$HOME`-based version that first rewrote the home directory to `~` and then
-/// matched `~/…`, which had two bugs:
+/// matched `~/...`, which had two bugs:
 ///
 /// - `$HOME` was substituted by plain substring match, so a checkout whose path merely
 ///   *contains* `$HOME` was corrupted rather than normalised. With `HOME=/home/u`, the path
@@ -122,7 +122,7 @@ pub fn get_full_path_for_resource_file(path: &str) -> String {
 ///
 /// Anchoring on the crate directory also leaves URLs alone by construction, which a regex over
 /// bare absolute paths would not: the SARIF fixtures contain
-/// `//docs.oasis-open.org/…/sarif-schema-2.1.0.json`, and reducing that to its basename would
+/// `//docs.oasis-open.org/.../sarif-schema-2.1.0.json`, and reducing that to its basename would
 /// break them. It is the only slash-bearing file reference in `guard/resources`, so the
 /// distinction is load-bearing for exactly one fixture and easy to lose.
 pub fn replace_path_with_filenames(text: String) -> String {