rewrite: fix wrong index check in trimPathPrefix

[alhudz]

Repro: with uri strip_prefix /aaaaaa, a request for /%61%61 (which decodes to /aa) comes back rewritten to /aa instead of being left untouched. /aa is not under /aaaaaa, so nothing should be stripped.
Cause: trimPathPrefix walks the escaped path and the prefix in lock-step, then decides it matched with iPath >= len(prefix). iPath indexes the escaped request path while len(prefix) is the prefix length, so a short percent-encoded path whose byte length reaches len(prefix) exits the loop with the prefix only partly consumed yet still passes that check and is treated as a match. strip_path_suffix reaches the same code through the reversed call.
Fix: compare iPrefix against len(prefix) so a match requires the whole prefix to have been consumed.

Assistance Disclosure

I used an LLM to help analyse the loop and sanity-check the repro; I wrote and verified the fix and the regression test locally.

[CLAassistant]

All committers have signed the CLA.

[alhudz]

done!

[mholt]

Thanks; however the PR template is missing, can you please restore the assistance disclosure?

Also, the CLA still seems to not be signed -- maybe make sure your commits are with an email on your GH account.

[alhudz]

Restored the disclosure section in the PR body, sorry about dropping it.

The CLA failure was down to a typo in my commit email (al.hudz.k@ instead of alhudz.k@), so the commit wasn't linked to my account. Amended the author email and force-pushed; the branch is rebased on current master in the process.

[mholt]

Alright, thank you!