Introduce experimental new internal authz API

[alilleybrinker]

This introduces a new experimental authorization API and begins the process of testing it. It also includes refactors to the integration test suite, and the introduction of a new test:integration-local task to run the integration test suite fully locally.

This is best reviewed commit-by-commit.

In general, the fix is to add a rate‑limiting middleware into the route’s middleware chain so that expensive, authorized operations cannot be triggered arbitrarily often. In Express, this is commonly done using the well‑known express-rate-limit package. For minimal functional impact, we should define a limiter with reasonable defaults (e.g., window in minutes and a relatively high max count) and apply it only to this sensitive route (or a small set of similar routes) rather than globally.

Concretely for src/controller/cve.controller/index.js, we will:

• Import express-rate-limit near the top of the file, alongside the other require statements.
• Define a limiter instance dedicated to CVE modification routes, e.g., const cveUpdateLimiter = rateLimit({ ... }). A sensible baseline is something like a 15‑minute window and a fairly generous max count so normal users are unaffected.
• Insert this limiter into the route’s middleware chain before the controller, after authentication/authorization/validation middleware where appropriate. Since rate limiting is about how often the endpoint can be hit (regardless of payload validity), it can reasonably be placed early, but placing it after mw.validateUser ensures anonymous traffic cannot probe the limiter behavior; we will place it right after mw.validateUser and before the authorization selector.

We will only modify the shown region of index.js: add the import and limiter definition at the top and inject cveUpdateLimiter into the middleware list around line 587. No existing behavior of controller.CVE_UPDATE_SINGLE or the other middlewares will be changed.