Centralize DOMStack file conventions

[bcomnes]

Problem

DOMStack's file conventions are represented by filename and suffix lists in page discovery, then interpreted again by watch event classification, bundle entry collection, and static-copy exclusions.

Some constants are already shared.
The remaining duplication is in their meaning: whether a file is a page, layout asset, global asset, worker, settings module, or generated-page owner, and which build work it affects.
Adding a convention requires coordinating several separate branches.

Proposed direction

Introduce a small internal declarative registry for supported filenames and suffixes, their roles, and their static build/invalidation categories.
Extend the existing shared constants into reusable classification and selection helpers.

Keep runtime dependency decisions in the watch planner and dependency tracker.
The registry should describe file conventions without becoming a second dependency graph or a new public plugin API.

Acceptance criteria

• Discovery and watch classification use the same convention definitions.
• Bundle entry selection and copy exclusions reuse those definitions or clearly documented derived rules where applicable.
• Table-driven tests cover supported extensions, Node-dependent TypeScript support, draft names, precedence, and classification.
• Existing supported filenames, warnings, output paths, and granular rebuild behavior are preserved.
• Adding an ordinary supported extension or filename no longer requires duplicating classification rules across subsystems.

Sequencing

Implement against the result of #294.
Coordinate with the separate watch-planner extraction so the planner consumes the shared classification helpers.
This is a maintainability improvement after the watch correctness fixes, not a v12 release blocker.