Add the ability to store named queries/globs/selectors

[abegong]

Summary

Add a way for projects to define reusable, named selections: queries, globs, and selectors that can be referenced from commands instead of repeating long expressions.

Motivation

Several Katalyst workflows need the same subset of content repeatedly:

• "all docs under docs/ except generated output"
• "all notes tagged draft"
• "all README-like files"
• "all items in a collection matching a listing predicate"
• "the same corpus slice used by a check, inspect run, or example"

Today those selections live inline as command flags, config snippets, or ad hoc shell commands. That makes them hard to share, document, validate, or reuse consistently across check, fix, inspect, and item list.

Design questions

• Where do named selections live: project config, collection config, a new .katalyst/selections/ kind, or all of the above?
• What selection kinds are supported in the first cut?
  • collection/item selectors
  • filesystem globs
  • item list predicates / listing filters
  • inspector include/exclude filters, if those exist
• How are named selections referenced from the CLI?
  • katalyst check @drafts
  • katalyst inspect notes --selection readmes
  • katalyst item list notes --query drafts
• Do named selections compose, and if so how are cycles detected?
• Are selections scoped globally, per collection, or per command family?
• How does validation report an unknown or invalid named selection?

Possible shape

selections:
  draft-notes:
    collection: notes
    filter:
      - status=draft
  docs-readmes:
    path: docs
    include:
      - "**/README*.md"
    exclude:
      - "docs/generated/**"

This shape is illustrative only. The issue should settle vocabulary and config boundaries before implementation.

Acceptance criteria

• Projects can define at least one named selection and reference it from a CLI command.
• The first supported selection kinds are documented with examples.
• Invalid or unknown named selections produce Katalyst usage errors with actionable hints.
• Named selections are validated early enough that config mistakes are easy to diagnose.
• Docs explain when to use a named selection instead of inline selectors/globs/filters.
• go test ./... passes.

Related

• inspect include/exclude filters, if implemented, should either reuse this selection model or document why it stays separate.
• item list filtering/pagination terminology should stay aligned with the CLI style guide.