Narrow :manifest() + chained field accessor for RESULTS run-level reads - #273

Summary

$*.results.:flatten():manifest():named_file_uuid() -- David's own exact
worked example (meant to INTERSECT against the FILES-side uuid set from
the previous PR) -- now resolves to the field value, not the whole
manifest.json entry.

Background

The original framing was "does the undotted shape need to be made to
apply an accessor it currently discards, or should it raise." Traced
through _query_star_traversal(), _star_run_selector_chain(), and
_extract_data() in full before answering, rather than assuming either
diagnosis. Two things turned out different from the original framing:

1. _query_star_traversal()/_star_run_selector_chain() were already
   fine -- _star_run_selector_chain() already exempts :manifest()/a
   field accessor from its "unsupported function" rejection, and
   query() already produces real, per-run results regardless. Nothing
   needed changing there.
2. The actual bug lived entirely in _extract_data(), and it is not
   '*'-traversal-specific -- the identical bug affects the literal-root
   shape too ($acme.results.customers/2025:first():manifest() :named_file_uuid()), just never exercised by any existing test.
   _extract_data()'s has_manifest branch returned the whole
   manifest.json entry the moment :manifest() was present anywhere in
   name_one_calls, unconditionally -- before ever checking whether a
   field accessor was also chained alongside it. The run_field_call
   branch that already does that narrowing, just below it, was
   structurally unreachable whenever :manifest() was also present.

Also confirmed before building: :manifest() is not actually required
for a run-level field read at all -- $*.results.:flatten() :named_file_uuid() (no :manifest()) already worked correctly before
this PR, via the pre-existing run_field_call branch. :manifest()
chained alongside a field accessor is legal but redundant, the same
relationship the previous FILES PR's :first():uuid() vs.
:first():manifest():uuid() distinction already established -- not a
different, narrower shape needing its own separate design.

What changed

Widened _extract_data()'s has_manifest branch (shared by literal-root
and '*'-root, both funnel through the same method) to check for a field
accessor in name_one_calls after reading the entry, and -- if present
-- narrow to that field using the identical extraction logic
(function_cls.KEY, _extract_field_value_with_ledger_fallback()) the
sibling run_field_call branch already has, instead of returning the
whole entry. Bare :manifest() with no field accessor is unchanged.

Test plan

• '*' root: narrowing works with multiple pooled runs, no pointer
  (matches David's own syntax exactly).
• Regression: bare :manifest() alone still gives the whole entry.
• Field-accessor-before-:manifest() order also works
  (order-independence).
• Literal-root shape gets the identical fix.
• Combining with name_three still correctly raises.
• tests/references/ full tree: 1560 passed.
• Full suite run twice for stability: 3153 passed, 11 failed both
  times (identical) -- the known, unrelated SFTP/S3 failures
  requiring unset env vars (issue test_nos_server_config_1 crashes with a raw ValueError when SFTP_* env vars are unset, instead of failing clearly #216).

https://claude.ai/code/session_013gPjejPWvbWtjz2dw9h14M