Infer listing group from parent directory when frontmatter is absent

[Mpdreamz]

Why

The listing: directive groups files via explicit listing: <group> frontmatter. Content that's already organized into per-group subdirectories (e.g. reference/indentation/foo.md) shouldn't have to repeat that grouping in every file's frontmatter — it's redundant with the directory structure and easy to forget, silently dropping pages into the "ungrouped" bucket.

What

When a content file has no listing: frontmatter, ResolveListingRef now falls back to inferring the group from the file's parent directory, but only when that directory is a recognized group folder (i.e. it has a group index file). Explicit listing: frontmatter still takes precedence when present.

Made with Cursor

[Mpdreamz]

Local review notes from the queue pass, since this PR is authored by Mpdreamz and a formal self-review will not count as the required review:

• Please add focused coverage for the fallback behavior in ResolveListingRef. I would want at least: explicit listing: frontmatter still wins over directory inference, a file in a directory with a group index.md is inferred into that group, and a file in a directory without a group index.md remains ungrouped.

• The current inference only checks the file immediate parent directory: parentRel = Path.GetRelativePath(listingDirAbsolute, file.Directory.FullName). If listing content can be nested below a group, for example reference/indentation/examples/foo.md with reference/indentation/index.md, this would not infer indentation; it would look for indentation/examples/index.md and leave the page ungrouped. If nested files should stay in the nearest group folder, walk ancestors back toward the listing root and pick the first matching groupIndexFiles key. If only one-level group folders are supported, please lock that in with tests/docs.

• The failed assembler-preview check appears unrelated to this change. The log shows a 10-minute timeout while fetching docs-content (git fetch ... origin 77008788f7702e219b1dbfa8832e962ae8437b8d), not a listing/rendering error. Rerunning after the test update should be enough to verify the preview path.