fix: start postman listeners from latest in local env

[Othryades]

Use -1 for L1/L2 listener initial block in local postman config so e2e bridge claims are not delayed by replaying full chain history.

This PR fixes issue #1247

Checklist

• I wrote new tests for my new core changes.
• I have successfully ran tests, style checker and build against my new changes locally.
• I have informed the team of any breaking changes if there are any.

---

Note

Low Risk
Only changes local Docker environment defaults/comments; no production code paths or security-sensitive logic are modified.

Overview
Local Postman Docker env config now defaults L1_LISTENER_INITIAL_FROM_BLOCK and L2_LISTENER_INITIAL_FROM_BLOCK to -1 (start from latest) instead of 0 (genesis replay), with streamlined comments clarifying the intended local e2e behavior.

This reduces local startup/backfill time and avoids delays caused by replaying full chain history during end-to-end bridge flows.

^{Written by Cursor Bugbot for commit 83b2e6a. This will update automatically on new commits. Configure here.}

[jonesho]

@Othryades I'm keen on setting this to -1, but do you see it really helps the timeout issue? Set to -1 can speed up the event fetching, but iiuc, the impact could be quite miminal given the fresh L1 chain without too many blocks, same for L2_LISTENER_INITIAL_FROM_BLOCK

[VGau]

@Othryades We can put -1 but it won't fix the issue in the e2e tests because this param is useful when we restart the postman.
We always use a fresh local stack and the postman only start once so this change won't have any effect.