[merging June 30 at 4pm PT] making this an hard guideline & enforcing consistent reviews on upstream sglang/vllm docker repo to PR CheckList

docs/PR_REVIEW_CHECKLIST.md

@@ -9,8 +9,9 @@ As a PR reviewer and CODEOWNER, I have reviewed this and have:
 - [ ] Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
 - [ ] Verified that this PR has passed PR validation. Please link to GitHub Action workflow that shows this.
 - [ ] Verified that this PR passes evals.  Please link to GitHub Action workflow that shows this.
-- [ ] Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world 
-- [ ] If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
+- [ ] Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
+- [ ] If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have verified that the respective vLLM submission made using upstream https://hub.docker.com/u/vllm docker repo, upstream SGLang https://hub.docker.com/u/lmsysorg docker repo. The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet as supported by vLLM/SGLang community maintainers
+- [ ] If an company claims that they support vLLM/SGLang as first class upstream in-tree LLM inference engines on their hardware, I have have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
 - [ ] Verified that the single-node recipes are similar to the official [vLLM recipes](https://recipes.vllm.ai/) and/or the[SGLang cookbook](https://docs.sglang.io/cookbook/intro):
   - If they are not, I have verified that a PR has been opened in [vLLM recipe repo](https://github.com/vllm-project/recipes) or [SGLang repo](https://github.com/sgl-project/sglang/tree/main/docs_new) and linked it below in the additional detail section:
 - [ ] If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.