HTTP analysis ignores `expectedResponse`

Start in pkg/app/pipedv1/plugin/analysis/analysisprovider/http/http.go, then inspect AnalysisHTTP.ExpectedResponse in pkg/app/pipedv1/plugin/analysis/config/condition.go and the Provider.Run flow. Add or extend a unit test using httptest.Server for matching and non-matching response bodies. Done means the configured body assertion is applied, the matching rule is documented, and mismatch output is bounded without exposing an unbounded body.

What happened:

The pipedv1 HTTP analysis provider accepts an expectedResponse value in AnalysisHTTP, but it never reads or evaluates the HTTP response body. Provider.Run in pkg/app/pipedv1/plugin/analysis/analysisprovider/http/http.go only compares res.StatusCode with expectedCode and returns success immediately afterward.

As a result, an ANALYSIS stage passes when an endpoint returns the expected HTTP status but an unhealthy or otherwise unexpected response body. For example, a health endpoint returning 200 OK with {"status":"unhealthy"} passes even when expectedResponse is configured as {"status":"healthy"}.

What you expected to happen:

When expectedResponse is configured, the HTTP analysis should read the response body and fail the check when it does not match the configured expectation. A matching status code alone should not mark the analysis as successful when a body assertion is present.

The matching rule should be documented clearly (for example, exact body match or substring match), and failure output should identify the response-body mismatch without exposing an unbounded response body.

How to reproduce it:

1. Start an HTTP endpoint that always returns 200 OK with this body:

   {"status":"unhealthy"}
   

2. Configure an HTTP analysis check with a different expected response:

   https:
     - url: http://localhost:8080/healthz
       method: GET
       expectedCode: 200
       expectedResponse: '{"status":"healthy"}'
       interval: 10s
       timeout: 30s
   

3. Run an ANALYSIS stage that uses this check.

4. Observe that the check succeeds because the status code is 200, despite the body being {"status":"unhealthy"} rather than the configured expectedResponse.

The same behavior can be reproduced directly in a unit test with an httptest.Server that returns status 200 and a non-matching body, then calling http.Provider.Run with the configuration above.

Environment:

• piped version: reproduced from source at 3f7551c96 (replace with the release/image version if reproducing in a deployed environment)
• control-plane version: not version-specific; the behavior is in the pipedv1 HTTP analysis provider
• Others: pipedv1 analysis plugin; an HTTP endpoint that returns the configured status code with a non-matching body

Relevant code:

• pkg/app/pipedv1/plugin/analysis/config/condition.go declares AnalysisHTTP.ExpectedResponse.
• pkg/app/pipedv1/plugin/analysis/analysisprovider/http/http.go currently checks only ExpectedCode and contains a TODO for response-body evaluation.