Probe INFO and VERSION at login screen and capture replies in ProbeResult

[Copilot]

The probe previously relied on handshake, banner, WHO/DOING, and MSSP for codebase signal extraction. This change extends the login-screen read surface to include INFO and VERSION, so additional codebase/version hints are captured when exposed pre-login.

• Probe command surface

  • Expanded TelnetProbe.PermittedCommands from ["WHO"] to ["WHO", "INFO", "VERSION"].
  • Added dedicated probe phases for INFO and VERSION after WHO, preserving strict phase boundaries between banner/WHO/INFO/VERSION outputs.

• Probe result model

  • Added ProbeResult.Info and ProbeResult.Version (string?) to store raw login-screen replies from those commands.
  • Kept Who semantics unchanged (including parse confidence and count behavior).

• Behavioral/docs alignment

  • Updated crawl restraint expectations to assert the new permitted read-only command set.
  • Updated about-page probe wording to reflect multiple read-only login-screen commands instead of a single WHO command.

• Session-level coverage

  • Extended in-process probe session test harness to emulate INFO/VERSION responses.
  • Added coverage that INFO/VERSION replies are captured independently and do not bleed into banner/WHO evidence.

public static readonly IReadOnlyList<string> PermittedCommands =
    [WhoCommand, InfoCommand, VersionCommand];

// ...
await telnet.SendAsync(Encoding.ASCII.GetBytes(InfoCommand));
await telnet.SendAsync(Encoding.ASCII.GetBytes(VersionCommand));

// ...
Info = infoText.Length == 0 ? null : infoText,
Version = versionText.Length == 0 ? null : versionText,

• Fixes INFO & version #22

[HarryCordewener]

An example of INFO:

[HarryCordewener]

An example of VERSION:

[HarryCordewener]

@copilot Two comments showing images of what INFO and VERSION may look like. Be away, these are not the only layouts!

Do research based on the sourcecode for PennMUSH, TinyMUSH, TinyMUX, and all the other codebases we already have recorded in our documentation, to get an idea of these types of commands available to us at login, and how to parse them.

[Copilot]

@copilot Two comments showing images of what INFO and VERSION may look like. Be away, these are not the only layouts!

Do research based on the sourcecode for PennMUSH, TinyMUSH, TinyMUX, and all t...

Implemented in 57d5eca and broadened in 134a7e4.

I checked source layouts across MUSH and non-MUSH families (PennMUSH, TinyMUSH, TinyMUX, RhostMUSH, plus DIKU/Circle-style code):

• MUSH variants commonly expose labelled Version:/Codebase: lines or family+version strings.
• DIKU/Circle info is often a static page text (page_string(info, ...)) and not a reliable codebase/version signal.

The parser is now intentionally conservative:

• Reads explicit labelled values (Codebase:, Version:, etc.).
• Reads unlabelled version lines only when they clearly include a known MU* family + numeric version.
• Handles TinyMUSH-style heading + numeric Version: by combining detected family heading with the version value.
• Avoids generic INFO prose so we don’t fabricate identity signals from non-version text.

Added targeted tests in Crawl and Discovery for these shapes, including the Rhost-style INFO block and TinyMUSH/TinyMUX patterns.