[jiro-by-nori]

Summary

Fixes #64: IO#gets, and therefore IO#readline/IO#each_line, now honours the global input record separator $/ instead of always splitting on "\n".

• $/ is read at each call, so changing it between reads takes effect.
• Unset $/ keeps CRuby's default "\n".
• $/ = nil reads to end of file.
• A String $/ is used verbatim as the separator, including multi-character separators.
• The limit-only form gets(n) also uses $/, as CRuby does.
• Paragraph mode ($/ = "") and non-String/non-nil separators gate by name instead of answering an approximated line.

The change also adds the framing lemma getsArgsH_frame (framing must not change the machine's globals) and runtime controls that pin the separator matrix against the boot fixture /tmp/vfsdata/nums.txt.

This PR is stacked on the step-5 work in #36. Its base branch jiro/vfs-step5-signed is a signed copy of #36's tip (nori-git has to re-sign unsigned feature commits to publish them); the diff shown here is only the $/ change. It depends on step 5's descriptor gets landing first.

Test plan

• cd books && lake build (all 1,397 targets, including the new InputRecordSeparatorControls).
• Ran the model and CRuby 4.0.5 with bin/ruby-lean --compare over the fixture /tmp/vfsdata/nums.txt ("1\n2\n3\n") for:
  • default $/ → "1\n"
  • $/ = "2" → "1\n2", then "\n3\n"
  • $/ = nil → "1\n2\n3\n", then nil
  • $/ = "2" with gets(2) → "1\n"
  • $/ = "2" with readline and the block form of each_line
• Confirmed $/ = "" gates with IO#gets: paragraph mode (an empty record separator) is not modelled rather than returning a guessed line.

Authored by Jiro, an agent: both the code and this description.

[jiro-by-nori]

Closing this stacked PR: its base is the pre-November VFS step-5 branch, which predates scripts/check-not-weakened.py; the required check runs from main and cannot find the script in that old base. The $/ change is preserved on jiro/issue-64-input-record-separator and can be rebased onto the step-5 stack once that lands. Filed the separate Pathname#empty? wrong answer as #91.