A module cannot touch the request pipeline, so caching and rate limiting can never be modules

`IBarakoModule` has no way to touch the request pipeline. Its members are `ConfigureServices`, `ConfigureSchema`, `ConfigureMarten`, `EndpointAssemblies`, `SchemaAssemblies` and `SeedAsync`. Nothing in `barakoCMS/Modules/` mentions `IApplicationBuilder`, `WebApplication` or `UseMiddleware`, and `UseBarakoCMS` (`barakoCMS/Extensions/ServiceCollectionExtensions.cs:1069`) never asks a module for anything.

So a module can add endpoints and documents, and it cannot change how an existing route responds. Output caching, response caching, compression and rate limiting are all middleware. None of them can ship as a module today, which means every one of them has to land in core or not at all.

## What to add

A hook called at a defined point inside `UseBarakoCMS`, with a default no-op so existing modules keep compiling:

```csharp
void ConfigureApp(IApplicationBuilder app) { }
```

The hard part is not the signature, it is saying where it runs. Middleware order decides behaviour, so the contract has to name the position: after tenant resolution and authentication, before endpoint routing, is the position that lets a module cache or throttle a request that has already been attributed to a tenant and a caller. Write that down in `MODULES.md` and prove it with a test, because a hook whose position is undocumented is a hook nobody can use correctly.

## Why this is a 4.0 item

Adding a member with a default implementation does not move `ModuleContract.Version` by the rule in `ModuleContract.cs`. But the ordering guarantee is the part third-party modules will build on, and changing where the hook runs later would silently break them. That is a one-way door, and 4.0 is where one-way doors go.

## Done when

- A module can register middleware, and a test proves the middleware sees a resolved tenant.
- `MODULES.md` states the position in the pipeline and what a module may and may not do there.
- A module that does not implement the hook behaves exactly as it does today.

Blocks the response-caching and rate-limiting work, both of which are otherwise core-only.

Start with IBarakoModule and UseBarakoCMS in barakoCMS/Extensions/ServiceCollectionExtensions.cs:1069, then read ModuleContract.cs and MODULES.md for compatibility and ordering constraints. Add a focused module test proving middleware sees a resolved tenant, document the hook position and limits in MODULES.md, and verify modules without the hook behave unchanged.

Written by the indexing model from the issue text.