No supported way to supply the RAMSES full-version licence record

[apetros]

Problem

The free RAMSES build stops at network reading with

STOP CALL FROM Get buses:
You do not have license for more than  1000 buses. Please contact the authors.

The full version is unlocked by a settings record of the form

$LICENSE <email> <64-hex-character key> ;

but the package offers no way to supply one. The only route today is to hand-edit a
settings or data file of the case being run. That has two bad consequences:

1. The key lands in case data. Test-system repositories keep their settings.dat
   under version control, so pasting the record there publishes a personal licence key.
   The workaround is to keep a separate license.dat holding only the record and add it
   with addData('license.dat'), which works but every user has to reinvent it and
   remember to gitignore it.
2. It is per case, not per installation. A licensed user has to repeat the edit for
   every case they touch, and any case shared with them arrives without it.

Verified locally: a data file containing only the $LICENSE record, added through
addData(), does lift the limit. A 24,625-bus network then initialises and simulates
normally, so the only thing missing is a supported way to hand the record to the engine.

Suggestion

Let the licence be configured once per installation and injected automatically into
every case. Roughly, in order of preference:

• A stored credential, for example stepss.set_license(email, key) writing to a config
  file in the platform user-config directory, with stepss.get_license() and
  stepss.clear_license() alongside it.
• Environment variables (STEPSS_LICENSE_EMAIL, STEPSS_LICENSE_KEY) for CI and
  containers, taking precedence over the stored credential.
• cfg then appends the record to the generated command file at execSim() time, so no
  user-visible data file ever holds the key.

Worth deciding as part of this:

• What to do when both a stored licence and a $LICENSE record in the case data are
  present. Silently preferring one is a debugging trap; a warning seems right.
• Whether to validate the key locally (it is 64 hex characters and bound to the email)
  so a typo reports itself, instead of surfacing as the misleading 1000-bus message.
• Whether build_info() or a new call should report whether a full licence is active,
  since today the banner prints (Full Version) regardless.

See the companion issue in stepss-java-ui for the GUI side, which should read the same
stored credential so the two interfaces do not each keep their own copy.