SET PROCEDURE: routines in procedure files are found

[jefflroberts]

SET PROCEDURE TO was accepted and ignored, so a bare call into a procedure file failed, which stops a CodeMine application at its first line. Now the files are loaded through the host's LoadProgram, as DO loads a program, without running their main body. A bare call or DO looks in the current program, then the procedure files in the order listed, then the programs that have run.

Measured in Visual FoxPro 9 and written into the set_procedure golden, whose .expected was produced by vfp9.exe:

• ADDITIVE appends; a file already listed stays where it is.
• Without ADDITIVE the list is emptied first and files go on as they load, so a missing file (error 1, "File 'x.prg' does not exist.") keeps the ones before it and drops what was listed before.
• RELEASE PROCEDURE takes a file off, and its routines stop being found, while a program that ran with DO keeps its routines findable after it returns.
• SET("PROCEDURE") answers each file's full .FXP path, quoted, comma-separated.
• A call to a name that is no routine anywhere runs the program of that name, and is error 1 when there is none (it was error 1162).
• DO name+"text" builds the program's name when the + is written against the name; with spaces round it the product calls it a syntax error (DO: prg name concatenation doesn't work #1).

The mock host can now hold program sources and load one when LoadProgram asks, which is how the golden gets its procedure files through the same path the IDE's host takes. The IDE's own "does not exist" message now uses the product's wording, and SET PROCEDURE moves from "accepted and ignored" to "runs" in the language coverage map.

Verification. The set_procedure golden, crates/foxvm/tests/procedures.rs, and the full VM suite.

This is independent of #2. A few more pull requests from the same application (a CodeMine app, Shutter Ace) will follow, split by topic.

Closes #3. Fixes #1.

🤖 Generated with Claude Code

[RandomChirp]

The golden set_procedure.prg agrees with vfp9.exe, the fixtures are ASCII, and cargo test -p foxvm is green on a merge with main.

I measured the DO rule the parser encodes: DO p_cod+"x" written without spaces runs, the same line with spaces round the + is error 10, and DO (expr) runs. That is what the product does, so the unspaced-only rule is right.

One thing before it can merge: main now has a DO "quoted name" block at the same spot in crates/foxvm/src/parser.rs (from #2), so the branch conflicts. The resolution that passes every test is to keep the quoted-name block from main first, with its own tail, and put this branch's name+expression block after it, with its tail. A rebase on main with that ordering is all it needs.

Review generated with Claude Code (Claude Fable 5.1), run against vfp9.exe and the test suites on a merge with main.