Support depth-bounded glob patterns (or a depth: field) on collections

[abegong]

Use case

I want to enforce: "the only files/directories at the root of projects/ are README.md, ongoing/, and episodic/" — i.e. a whitelist of direct children only, with no opinion on what lives deeper inside ongoing/ or episodic/.

Current behavior

A collection defined with:

projects-root:
  path: .
  pattern: "*"
  checks:
    - kind: filesystem_name_regex
      target: filename-ext
      pattern: "README\\.md|ongoing|episodic"

walks recursively (* matches at every depth), which means:

• Stray files deep in the tree get flagged as violations.
• Subdirectories at depth 0 (ongoing/, episodic/, one-time/, sunday-school-scheduling/) are reported as read … is a directory and excluded from check evaluation — so the whitelist regex never gets a chance to flag the disallowed ones.

filesystem_path_depth exists as a per-item check, but it runs after discovery and doesn't constrain the discovery itself, so it doesn't compose to "only consider depth 0."

Suggested fix

Either:

1. A depth: (or max_depth: 0) field on collection definitions that bounds discovery. E.g.:

projects-root:
  path: .
  pattern: "*"
  max_depth: 0

2. Or, make glob semantics interpret * as "direct children only" and **/* as "recursive" (rsync/gitignore-style). Today both seem to behave recursively.

Either gives users a clean way to express "shallow whitelist."

Bonus: directories as items

Related: directories at the collection root currently produce read … is a directory lines and are skipped, so checks like filesystem_name_regex can't fire against them. A directories: include option (or treating directories as items when no extension filter applies) would let the whitelist actually catch disallowed subdirs like one-time/.