cosec-custom-matcherlisted

# CoSec Custom Matchers Add a matcher only after confirming that the built-ins cannot express the rule. Prefer composing `path`, `bool`, part matchers, or the local/Redis rate limiters over new code. ## Extension contract - `ActionMatcher` and `ConditionMatcher` live in `cosec-api` and extend `RequestMatcher`. - Their factory interfaces and providers live in `cosec-core` under `me.ahoo.cosec.policy.action` and `me.ahoo.cosec.policy.condition`. - A factory's `type` is the object key used in policy JSON. It must not collide with another factory; later registration replaces the existing entry. - Do not change the SPI interfaces to add a matcher. Implement them and register the factory. - Keep matching synchronous and side-effect free unless the matcher intentionally enforces a stateful control such as rate limiting. Before editing, inspect the target CoSec version's interfaces and the nearest built-in matcher. In a CoSec checkout, the authoritative files are: - `cosec-api/src/main/kotlin/me/ahoo/cosec/api/principal/RequestMatcher.kt` - `cosec-core/src/main/kotlin/me/ahoo/cosec/policy/action/` - `cosec-core/src/main/kotlin/me/ahoo/cosec/policy/condition/` ## Minimal condition matcher Use `AbstractConditionMatcher` when `negate` support is desirable. Parse and validate configuration once during construction, not on every request. ```kotlin class PremiumUserConditionMatcher(configuration: Configuration) : AbstractConditionMatcher(PremiumUserConditionMatcherFactory.TYPE,