resolve the slice function from the criterion line, not the file name

[samiujan]

Fixes the default function resolution in rgctl slice. Based on main (8f09655).

Without --function, the function to slice within was guessed from the file stem (and the literal "process" for Python). Two failure modes followed, and the second misreported the cause:

// src/probe.ts holds `calc`
slice src/probe.ts --line 3 --variable y
  before: Error: Resource not found: function 'probe' not found
  after:  { "lines": [2, 3] }

// useAgentPositions.ts holds useAgentPositions (1-4) and fetchPositions (6-10)
slice src/useAgentPositions.ts --line 8 --variable total
  before: no PDG node for total at line 8       # blames the variable and line
  after:  { "lines": [7, 8] }

The second is the costly one: it names the variable and the line — both supplied by the caller and both correct — while the real cause is the function they never supplied and did not know was being guessed. It reads as a broken PDG, so the response is to try other lines and variables rather than to pass --function, which the error never mentions.

Fix: resolve the function that contains the criterion line, using the existing index_function_locations. --function still wins. Nested functions mean several spans can contain a line, so take the innermost. If no span contains the line, the historical stem fallback is kept, so behaviour changes only where the old default was plainly wrong.

Also name the function searched when a criterion lookup fails:

Error: Resource not found: no PDG node for total at line 8 — searched only
'useAgentPositions' (from --function). This file defines: 'fetchPositions', 'useAgentPositions'.

Unrelated errors pass through unchanged.

Verified: 7 new tests (1-based line mapping, out-of-range, resolution across two functions, innermost-span preference, no-match, error annotation, and pass-through). Full lib suite adds no new failures — the two failures present (languages::registry::tests::test_registry_creation, cli::agent_pack::tests::embedded_pack_lists_cursor_skills) reproduce on a clean main with no changes. fmt and clippy add no new findings.

Fixes #114. (Opening on sshaaf/rgctl, where #114 resolves to the reported issue, so the keyword
links and auto-closes it. This branch is also staged in the fork as samiujan#3, where a closing
keyword would point at a fork-local issue that does not exist.)

[sshaaf]

Thanks for this, Sami — really clear write-up of the failure mode, and the fix matches how people actually use slice (point at a line, don’t invent a function from the filename).

I ran the new cli::slice::tests locally: 7/7 passed. The error annotation that names the searched function (and lists candidates) is a genuine UX win.

One small correctness niggle inline below on the span check — happy to land this once that’s a half-open range. Appreciate the careful tests and the “leave unrelated errors alone” coverage.

[sshaaf]

Tiny span boundary note: FunctionLocation::end_byte is documented as exclusive (see cfg_builder.rs). Using offset <= loc.end_byte makes the range closed on the right.

At a boundary where function A’s exclusive end equals function B’s start, A can also match, and min_by_key might pick the wrong one.

Suggested:

.filter(|(_, loc)| loc.start_byte <= offset && offset < loc.end_byte)

A tiny adjacent-functions test would lock that in if you fancy — not blocking if you prefer to keep this PR lean.

[sshaaf]

Nice touch wiring name_the_function_searched only around the slice criterion lookup. Matching on no PDG node for (and leaving other errors untouched) is exactly the right scope — thanks for testing the pass-through case too.

[samiujan]

Span check is half-open now — offset < loc.end_byte, as you suggested. At a boundary where one function's exclusive end equals the next's start, both spans contained the offset and the tie went to whichever min_by_key saw first, which is the one case this function exists to resolve.

Added the adjacent-functions test you mentioned. It lays the bytes out explicitly rather than parsing, and it's verified by mutation: restoring <= makes it fail on the boundary offset, so it pins the behaviour rather than passing alongside it.

Nothing else outstanding from your review.