feat(validation)!: run startup checks as pluggable rules

[illia1f]

Startup validation was one method with every check inlined. Adding a check meant editing RegistrationValidator, and a package built on RequestFlow had no way to add one at all.

Validation now runs as a list of rules. A rule reads the whole registration picture off RequestFlowValidationContext and reports into the same exception as the built-in checks. The built-in checks are rules themselves, and AddValidationRule<T>() appends to the list.

• The model lives in RequestFlow.Abstractions, so a rule can ship in an assembly that never references the DI package. Lifetimes come through as RequestFlowLifetime instead of the container's ServiceLifetime, and a handler or stage reports the contract it implements as ContractType, so a kind layered on a core contract, such as ICommandHandler, arrives under its own name. Every list on the model is read-only.
• RequestFlowModelBuilder builds a RequestFlowModel by hand and BuildContext wraps one in the context a rule receives, which is how a rule is unit tested without a container.
• A rule that throws is reported as RF0107, and the rules after it still run.
• Two checks are new. RF0106 catches a request implementing more than one IRequest<TResponse>, which used to pass the freeze and then fail every dispatch under it with ResponseTypeMismatchException. CQRS0001 catches a request that AddCqrs classifies as both a command and a query.
• RF0104 now reports one problem per stage-class collision instead of a line per colliding pair, and no longer fires for two closings of one stage class on a request with more than one handler. That request already fails RF0101, and the collision surfaces once the duplicate handler is gone.
• docs/validation-rules.md covers writing, registering, and testing a rule. samples/Orders.Api is a minimal API wired with two custom rules, a validation stage, and a logging stage; samples/Orders.Api.Violations is the same wiring with the mistakes left in, so the exception can be read against real code.

BREAKING CHANGE: RequestFlowValidationException.Problems holds RequestFlowValidationProblem values (stable code, message, offending type) instead of strings, and the public constructor takes the same list, so a call site passing strings no longer compiles. Message lines now read RF0101: ..., so anything matching the old text breaks. Repeated registrations collapse into one problem each, where a request with three handlers used to report two identical lines. ProblemCodes and CqrsProblemCodes ship in the abstractions packages, so match ProblemCodes.UnhandledRequest rather than a literal string.