Offhand, I don’t see anything wrong there.
This statement is confusing me:
I did not have &loginResourceId in any of my Login calls. Setting it to a published resource in the context does not seem to have any affect (it will redirect to the id if logging in from another page).
I don’t know what the part in parentheses means.
Let me throw out some general things to check/try:
You should have two separate login pages, one for each context, created in that context.
Each should redirect to a page in its own context.
The login snippet should always be called uncached: [[!Login]]
Be sure to flush permissions and sessions and clear the cache after any change.
If none of that helps, I would remove all the ACL entries (both Context and Resource) except the two original Context Access ACL entries for the Admin to the mgr and web contexts (you can leave all the groups and the extra context). Then flush permissions, clear the cache and your browser cache/cookies, then flush sessions. That should leave your other context and its pages completely unprotected in the front end. If you still have the problem, it’s not a permissions problem. If the problem is gone, you can test as you add each ACL entry to see when things go south.