Return calculated pixels in "pixels" field for a rendition in API response

Nobody has claimed this yet.

Currently, the pixels field for a rendition in the API response is whatever value is contained in the pixels field for the API request. I think this is confusing. Instead, the pixels field for a rendition in the API response should contain the value calculated by the verifier so that the user of the verifier can compare the value with an expected value.

The verifier already calculates the pixels, but this information is incorporated into the `pixels_pre_verification` and `pixels_post_verification` fields with the former being the ratio b/w the expected pixels (indicated in the request) and the pixels calculated based on metadata and the latter being the ratio b/w the expected pixels and the pixels calculated based on reading the frames.

Note that while working on this issue we should also look into whether the pixels calculated by the verifier matches up with the pixels calculated by LPMS. I saw in some local testing with a verifier + broadcaster + orchestrator an API response with `pixels_post_verification: 6.0` which would imply that the verifier calculated a different # of pixels than the expected value passed to the verifier by the broadcaster which is calculated by LPMS (on the orchestrator)...

Start with the verifier's calculated pixel values and the code that builds the rendition API response. Compare those values with the pixels supplied by LPMS through the broadcaster and orchestrator, including the pixels_pre_verification and pixels_post_verification ratios. Done means the response's pixels field reports the verifier-calculated value and any discrepancy with LPMS is understood.

Written by the indexing model from the issue text.