docs(testing): document flash-testing and the limits it deliberately keeps

README covers the application handle, requests and assertions, service
replacement, multi-server wiring, scope, WebSockets, configuration and the
teardown ordering.

limits.md records the seven things the harness cannot do and what to use for
each: TLS, HTTP/2, WebSocket over HTTP/2, malformed requests, response framing,
the flash core module's dependency cycle, and scoped services. Each is a
consequence of a real constraint rather than an unfinished feature, so writing
them down stops the next person rediscovering them one at a time.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -146,6 +146,7 @@ See extension-specific READMEs for full details:
 - [`flash-ext-mcp`](flash-extensions/flash-ext-mcp/docs/README.md)
 - [`flash-ext-view-jte`](flash-extensions/flash-ext-view-jte/README.md)
 - [`flash-ext-view-thymeleaf`](flash-extensions/flash-ext-view-thymeleaf/README.md)
+- [`flash-testing`](flash-testing/docs/README.md)
 
 ## Error handlers
 
@@ -482,6 +483,9 @@ That is stock JUnit field semantics — the isolation switch is the keyword, not
 
 ### Configuration
 
+Full reference: [`flash-testing/docs`](flash-testing/docs/README.md), including the
+[limits](flash-testing/docs/limits.md) the harness deliberately does not cross.
+
 `profile` customises the `FlashConfiguration` — timeouts, HTTP/2 switches, buffer sizes. Host, port
 and the shutdown drain window are stamped afterwards, so a profile cannot break the harness;
 `listener(...)` and `tls(...)` are rejected because the harness owns the loopback listener it gives