.csx files: Roslyn scripting globals (`Args`) not injected, so scripts won't compile

LINQPad opens and parses .csx files, and supports the CSX-style #r "nuget: ..."
directive, so a dotnet-script file looks like it's understood. But it's compiled as a
normal C# Statements script without Roslyn's scripting globals, so any use of Args
fails with:

CS0103: The name 'Args' does not exist in the current context

In Roslyn's scripting host, Args is an instance property on
Microsoft.CodeAnalysis.Scripting.Hosting.CommandLineScriptGlobals, passed as the
globals object and bound as the script's receiver. dotnet-script uses this, so bare
Args resolves there. There's no static accessor, so nothing in the script or a
referenced library can substitute for it directly.

There's no workaround from inside LINQPad:

• Environment.GetCommandLineArgs() under the GUI returns the host's command line
  (LINQPad.ScriptHost.dll, *:PS, port numbers, driver names) and never contains the
  script's arguments.

• Main(string[] args) works but requires C# Program mode, which isn't valid CSX — in a
  .csx, a declared Main is just an uncalled method, since the top-level statements
  are the entry point.

Request

For .csx files, put an Args in scope (an IList<string>), populated from the
command-line arguments field in Script Properties (F4 > Advanced), and from LPRun's
arguments when run via LPRun. Matching Print / PrintOptions from
CommandLineScriptGlobals would complete the surface, but Args is the one that
actually blocks scripts from compiling.

Why it matters

LINQPad is now more or less the last IDE that can debug .csx — VS Code's C# extension
dropped CSX debugging and Visual Studio's C# Interactive never really covered it. That's
a genuine niche LINQPad occupies, and this one missing symbol is what stands between it
and working.

Repro

Open any .csx containing:

Args.Dump();

CS0103 on Args.