fix: default gorRoot to absolute CWD instead of the literal string "./"

[gorfather]

Problem

When -gorroot is omitted, GorSessionFactory.updateCommonRoot() (and DriverBackedFileReader's own matching default) falls back to the literal string "./". Resolving a relative path against "./" is a no-op in this codebase's URI-based path resolution (PathUtils.resolve: resolving anything against a relative base just returns it unchanged), so any code path that needed real anchoring against this default silently got an un-anchored relative path back instead.

This surfaces concretely in PGOR's dictionary-folder write path: a direct pgor <sources> | write <target>.gord (no -gorroot given) fails with a spurious Resource Error on a fabricated version_XXXX.gord name, even though the write's own underlying computation succeeds. GeneralQueryHandler.getResultsLinkPath's .gord.link bookkeeping resolves the write target against this un-anchored root, produces a bare relative string with no directory information, and something downstream mis-resolves it against the wrong base.

Repro (no -gorroot, -cachedir only — the common case for any caller that doesn't explicitly pass a project root):

$ gorpipe "pgor f1.gor f2.gor | write out.gord" -cachedir /tmp/cache
==== Resource Error ====
Command GOR in pipe step #1 has a missing resource:
Input source does not exist: /tmp/cache/xx/out.gord/version_XXXXXXXX.gord

Supplying an explicit, absolute -gorroot has always worked around this; the actual bug is that the default was never a usable root to begin with.

Fix

Default to the process's actual absolute CWD (Paths.get("").toAbsolutePath()) instead of the literal string "./", in both places this default is computed.

Verified

• Both binaries (this repo, and a downstream fork) rebuilt and confirmed: pgor <sources> | write <target>.gord with only -cachedir (no -gorroot) now succeeds and returns correct data, matching a real caller's actual invocation shape.
• This default is never consulted for access-control decisions: DriverBackedFileReader.validateAccess() is a no-op, and the real enforcement path (DriverBackedSecureFileReader) always sources its project root independently (raw PipeOptions.gorRoot()/deployment-specific env vars, never through updateCommonRoot()) — so this change only affects path-resolution/anchoring correctness, not security scoping.

🤖 Generated with Claude Code