docs: use absolute links for our pages

Since 56b2970 has proven to be a no-go for us, as it breaks existing
links, let's embrace the trailing slash and use absolute links
everywhere for our pages. This way we'll get around browser cleverly
appending the relative link to the current location (since it ends with
a slash), and given our docs/ layout is flat it's not much of a hassle
either.

Converted using this beauty:
  $ sed -ri 's/(\[.+\]\()([A-Z_]+\))/\1\/\2/g' *.md

Resolves: #32088 (again) and #32310

1 files changed, 7 insertions, 7 deletions

diff --git a/docs/USER_RECORD.md b/docs/USER_RECORD.md
index 3b4fb4ae51..0268cc1230 100644
--- a/docs/USER_RECORD.md
+++ b/docs/USER_RECORD.md
@@ -16,7 +16,7 @@ Specifically:
 1. [`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
    manages `human` user home directories and embeds these JSON records
    directly in the home directory images
-   (see [Home Directories](HOME_DIRECTORY) for details).
+   (see [Home Directories](/HOME_DIRECTORY) for details).
 
 2. [`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
    processes these JSON records for users that log in, and applies various
@@ -72,15 +72,15 @@ the following extensions are envisioned:
 4. Default parameters for backup applications and similar
 
 Similar to JSON User Records there are also
-[JSON Group Records](GROUP_RECORD) that encapsulate UNIX groups.
+[JSON Group Records](/GROUP_RECORD) that encapsulate UNIX groups.
 
 JSON User Records are not suitable for storing all identity information about
 the user, such as binary data or large unstructured blobs of text. These parts
-of a user's identity should be stored in the [Blob Directories](USER_RECORD_BLOB_DIRS).
+of a user's identity should be stored in the [Blob Directories](/USER_RECORD_BLOB_DIRS).
 
 JSON User Records may be transferred or written to disk in various protocols
 and formats. To inquire about such records defined on the local system use the
-[User/Group Lookup API via Varlink](USER_GROUP_API). User/group records may
+[User/Group Lookup API via Varlink](/USER_GROUP_API). User/group records may
 also be dropped in number of drop-in directories as files. See
 [`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
 for details.
@@ -211,7 +211,7 @@ The following fields are currently defined:
 Takes a string with a valid UNIX user name.
 This field is the only mandatory field, all others are optional.
 Corresponds with the `pw_name` field of `struct passwd` and the `sp_namp` field of `struct spwd` (i.e. the shadow user record stored in `/etc/shadow`).
-See [User/Group Name Syntax](USER_NAMES)
+See [User/Group Name Syntax](/USER_NAMES)
 for the (relaxed) rules the various systemd components enforce on user/group names.
 
 `realm` → The "realm" a user is defined in.
@@ -227,10 +227,10 @@ A user record with a realm set is never compatible (for the purpose of updates,
 see above) with a user record without one set, even if the `userName` field matches.
 
 `blobDirectory` → The absolute path to a world-readable copy of the user's blob
-directory. See [Blob Directories](USER_RECORD_BLOB_DIRS) for more details.
+directory. See [Blob Directories](/USER_RECORD_BLOB_DIRS) for more details.
 
 `blobManifest` → An object, which maps valid blob directory filenames (see
-[Blob Directories](USER_RECORD_BLOB_DIRS) for requirements) to SHA256 hashes
+[Blob Directories](/USER_RECORD_BLOB_DIRS) for requirements) to SHA256 hashes
 formatted as hex strings. This exists for the purpose of including the contents
 of the blob directory in the record's signature. Managers that support blob
 directories and utilize signed user records (like `systemd-homed`) should use