powershell incorrect special char encoding (`§`) in runner 15.7.3+

Summary

Steps to reproduce

Using special characters anywhere in CI/CD job with PowerShell Windows runner results in incorrect character.

.gitlab-ci.yml
variables:
  TEST_FOLDER: "\xA7TestsOut\\Debug\\net48"
  TEST_FOLDER2: '§TestsOut2\Debug\net48'
    
stages:
  - build

build_debug:
  stage: build
  tags:
    - powershell-runner-15-7-3
  except:
    - tags
  script:
    - dir
    - '$env:TEST_FOLDER'
    - New-Item  -Name "$env:TEST_FOLDER" -ItemType "directory"
    - dir
    - '$env:TEST_FOLDER2'
    - New-Item  -Name "$env:TEST_FOLDER2" -ItemType "directory"
    - New-Item  -Name "§TestsOut3\Debug\net48" -ItemType "directory"
  artifacts:
    name: Debug
    paths:
      - "${TEST_FOLDER}"
      - "${TEST_FOLDER2}"

Actual behavior

The directory created in scripts is created with ┬º character instead of §. You can also see that character later on when the same directory gets uploaded as artifact:

image

image

Example job: https://gitlab.com/gitlab-gold/kategrechishkinatestgroup/zd404975-variable-expansion/-/jobs/4304788594

Expected behavior

Direcotry name is correctly expanded and created with § charter at the beginning, instead of ┬º. I am getting this behaviour with 15.7.0 version of the runner:

Example job: https://gitlab.com/gitlab-gold/kategrechishkinatestgroup/zd404975-variable-expansion/-/jobs/4268760895

Environment description

config.toml contents
concurrent = 1
check_interval = 0
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "windows-server"
  url = "https://gitlab.com"
  id = 0
  token = "TOKEN"
  token_obtained_at = 0001-01-01T00:00:00Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "shell"
  shell = "powershell"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]

Used GitLab Runner version

Possible fixes

There were two relevant MRs introduced between 15.7.0 and 15.7.3 that might have changed this behaviour:

Edited by Kate Grechishkina