v0.8.2 — run-script propagates script's return N as exit code (contract fix)

Closes `FR_runscript_propagate_script_return_value.md`. A `.csx` written as `Console.WriteLine("probe"); return 5;` now exits with code 5, not 0.

The documented behavior in `ScriptHost.RunAsync`'s XML remarks (and in `LLM/scripting.md` § "Exit codes from scripts" — "Returned int becomes the script-host's exit code") was a contract the implementation had never been honoring. Every successful script run returned 0 regardless of its return value.

Impact

ScripTree drivers and shell callers can now key red/green status off combridge's exit code without parsing the script's output text for status markers. The FR was filed while building the MergeInstanceMates ScripTree tool — its Python driver was parsing stdout for `ERROR:` / `FAIL` strings to reconstruct the status that should have come through `$?`. Every future status-bearing `.csx` would have needed the same workaround until this shipped.

Precedence

Bridge-level reserved codes (`2` file-not-found, `3` compile error, `4` script exception, `5` host failure) short-circuit before the script's return value is read. The `return N` path is reached ONLY when the script ran to completion. Reserved-code collisions (e.g. a script returning 4) are the author's problem to avoid.

Verified

Script	Exit code
`return 5;`	5 ✓
`return 42;`	42 ✓
no `return` statement	0 ✓
`throw` before `return 99;`	5 (HOST EXCEPTION precedence) ✓

VBScript path unaffected

The `.vbs` host already propagates `WScript.Quit(N)` as the exit code (verified in v0.8.0's smoke test: `WScript.Quit 42 → exit 42`). Only the Roslyn `.csx` path needed the fix.