Drop the claim that gemdb file.py leaves the script's directory off sys.path

README.md

@@ -370,9 +370,6 @@ The command needs no environment setup, and it starts the database if the databa
 Exit codes work the way scripts expect: 0 on success, 1 on an uncaught exception (with the error
 message on stderr), 2 for a missing file, and `sys.exit()` behaves as in CPython.
 
-One thing differs from `python3`: the script's directory is not included in `sys.path`, so the
-script cannot import a file next to it until it updates `sys.path` to include its directory.
-
 `input()` works in scripts, the GemDB Shell, and notebooks. A script reads stdin, and the GemDB
 Shell reads its own prompt line, where Ctrl+C raises `KeyboardInterrupt` and Ctrl+D raises
 `EOFError`. `print()` streams, so output appears while the code is still running.

docs/grail.md

@@ -264,9 +264,6 @@ issue rather than rediscovered:
   the process, by way of a catchable `KeyError` from `%(key)s` formatting and a
   real root logger. Both are upstream's claims and have not been re-measured
   here.
-- **`gemdb file.py` does not put the script's directory on `sys.path`** the way
-  `python3 file.py` does, and `sys.path` is otherwise empty, so a script cannot
-  import the file next to it until it inserts its own directory. (Grail #847.)
 - **A second application cannot reuse a module name the first one deployed.**
   From `beef473` on, importing a different file with different source under a
   module name already deployed raises `ImportError` instead of replacing it,