Keep the Mapillary access token out of exported configuration

Generated with the help of an LLM.

Problem/Motivation

The server access token is stored in mapillary.settings:access_token. When it is saved on the API settings form (/admin/config/services/mapillary/api), drush config:export writes it in plain text to mapillary.settings.yml in the sync directory, and from there it goes into the site's repository. Every developer who exports configuration commits the token, and every environment ends up with the same one.

The module already supports a settings.php override: the form field is then disabled, and an overridden value is not exported. But the README mentions it in one sentence, and nothing tells a site that its token is exported. An override also does not remove a token saved earlier: the stored value stays in active configuration and is still exported.

Ignoring mapillary.settings.yml in git does not solve this: the browser token and any later setting of the same object are no longer deployed, drush config:import treats the missing file as a deletion, and a token committed earlier stays in the history. Config Split does not solve it either, because split files are written to disk as well.

Steps to reproduce

1. Save an access token on /admin/config/services/mapillary/api.
2. Run drush config:export: mapillary.settings.yml contains the token.
3. Add $config['mapillary.settings']['access_token'] = 'another-token'; to settings.php and export again: the file still contains the first token.

Proposed resolution

• README: a section on keeping the token out of the repository. Read it from an environment variable in settings.php or settings.local.php, set only when the variable exists:
  if ($token = getenv('MAPILLARY_ACCESS_TOKEN')) { $config['mapillary.settings']['access_token'] = $token; }
  Then remove the stored value with drush config:set mapillary.settings access_token '' and export again. A token that was already committed stays in the git history and has to be treated as leaked and replaced. The browser token is sent to visitors and is not a secret, but it can be overridden the same way when each environment uses its own Mapillary app.
• README: when OAuth sign-in for Mapillary accounts is added, the module will use the Key module (drupal/key) for site-wide secrets such as the access token and the OAuth client secret. Until then, no new dependency.
• Status report: a "Mapillary access token" entry from hook_runtime_requirements() in MapillaryHooks, which reads the stored value without overrides:
  • overridden, nothing stored: OK, "Set in settings.php".
  • stored, not overridden: Info, the token is exported with the configuration, with a pointer to the README section.
  • overridden and stored: Warning, the stored token is not used but is still exported, with the drush config:set command that removes it.
  • neither: Warning, imports and the thumbnail refresh cannot call the API.
• The form keeps its current behaviour: no button to remove the stored token, since drush config:set does it and the status report names the command.
• Upgrade path: no schema or configuration change. An empty post update so that drush updatedb rebuilds the container and the new hook implementation is found.
• Tests: a kernel test for the four states of the status report entry, with the override set through $GLOBALS['config'].
• An "Added" entry under [Unreleased] in CHANGELOG.md.

Remaining tasks

• Merge request.
• Review.

User interface changes

• A "Mapillary access token" entry on the status report (/admin/reports/status).

API changes

• MapillaryHooks gets a constructor with ConfigFactoryInterface (autowired; the class is final).

Data model changes

None.