nixd/AST: drop lib.attrValues attribute keys from option paths

[ariofrio]

Motivation

A neat little idiom for organizing larger NixOS modules in a single file is to give each chunk of related configuration a name and merge them via lib.mkMerge (lib.attrValues { ... }). Each section attribute (ssh, caddy, etc.) is decorative — the merge collapses them at the option level — but the names document what each block does and let readers jump to them by attribute key:

{ lib, ... }: lib.mkMerge (lib.attrValues {
  ssh = {
    services.openssh.enable = true;
  };
  caddy = {
    services.caddy.enable = true;
  };
})

Today option hover and completion don't work inside these sections — the LSP returns no hover for enable. getValueAttrPath walks up to the surrounding { ssh = ...; caddy = ...; } attrset and prepends the section name to the path, because it doesn't know lib.attrValues discards keys.

Fix

When the enclosing ExprAttrs is the sole argument of a <x>.attrValues call, recurse past the call without appending the current binding's key. Matches both lib.attrValues and builtins.attrValues (any ExprSelect ending in .attrValues). False positives are bounded by the options-tree lookup — a misrecognized call only causes the analyzer to build a path that doesn't match any real option, producing no hover (same fail-closed behavior as today).

nixd/tools/nixd/test/hover/attrvalues-transparency.md covers this end-to-end. All 188 existing tests still pass.

Not yet handled

Neither of these is a regression — both already produce no hover on master:

• { imports = lib.attrValues {...}; } — the walker now lands in the surrounding { imports = …; } attrset and would append imports to the path. Needs a separate imports-key passthrough rule.

• Let-bound aliases like let av = lib.attrValues; in lib.mkMerge (av {...}) — the check matches the function expression syntactically, not through identifier rebinding. Following let/rec bindings in idioms::mkVarSelector would unblock this (and improve idiom resolution more broadly), as a separate PR.

[inclyc]

Why this PR is marked as 'draft'?

[inclyc]

The code itself LGTM, what I'm most concerned about right now is whether this idiom is actually widely adopted — meaning, have we perhaps found a pattern match that isn't all that complex but may not be entirely correct, and might not be very broadly used? Is this something officially recommended, or widely suggested by some kind of styling guide?