exclude: bare names match at every depth, anchored forms (/name, name/) match nothing

[JordanCoin]

Summary

exclude entries in .codemap/config.json match a bare name at any depth, and the gitignore-style anchored forms match nothing. So there's no way to exclude only a root-level entry. A common case hits this: a root build artifact that shares its name with a source directory (Go's cmd/<name>/ layout plus a <name> binary at the root). Excluding the binary silently removes the source directory from every view.

Repro (v4.5.1)

.
├── cmd/tool/main.go
├── lib.go
└── tool            # a built binary

exclude	files codemap reports
["tool"]	lib.go (the binary and cmd/tool/main.go are gone)
["/tool"]	cmd/tool/main.go, lib.go, tool (nothing excluded)
["tool/"]	cmd/tool/main.go, lib.go, tool (nothing excluded)

codemap cmd on that tree then reports Files: 0.

Why it's easy to miss

• --debug prints the root path and the gitignore cache, but not the active config path, the exclude list, or how many files the excludes removed.
• In a linked git worktree with no .codemap/, the config is read from the primary checkout (see config show / doctor resolve config to the primary checkout, not the current worktree #152). An exclude written there applies somewhere the user never wrote it, and nothing in the tree output or --debug says so. codemap config show does reveal it.
• Hook and skill output built on the scan inherits the gap without saying so.

Expected

• Follow gitignore semantics for exclude: a leading / anchors to the project root, and a trailing / matches directories only. Keep bare names matching at any depth for compatibility.
• --debug prints the config file in effect and the count (or a sample) of files each exclude removed.
• Consider a warning when an exclude removes files in one of the project's only source extensions. That's almost always unintended.