Self-hosted GHAR should not require a repository- or organization-wide token to remove itself

Describe the bug

This is a security bug

GHAR currently requires a repository- or organization-wide token to be able to remove itself via ./config.sh remove.
It does, however, present a security issue where GHAR cannot self-remove in an unattended manner without hosting a token on the runner. The runner itself is naturally insecure and thus a potentially malicious code could obtain an organization-wide token that is able to remove any runner in the repository or organization.

Expected behavior

1. Upon successful ./config.sh registration that does require a registration token the ./config.sh should be able to automatically obtain and persist (in a manner similar to /home/runner/.credentials and other security material) a single-use token scoped to the registered runner only.
2. When ./config.sh remove is then called without the --token argument, the single-use token obtained in [1] should be used to unregister self.

Runner Version and Platform

Version of your runner?
2.304.0

OS of the machine running the runner? OSX/Windows/Linux/...
Linux

What's not working?

N/A

Job Log Output

N/A

Runner and Worker's Diagnostic Logs

N/A

Start with ./config.sh and the existing /home/runner/.credentials handling described in the issue. Trace the registration and removal flows to determine where a runner-scoped, single-use token could be persisted and consumed. Done means removal works without --token while avoiding an organization-wide token on the runner.