The other log levels don't matter. It's just Apex = finest and Visualforce = finer (the log category I see is "Visualforce", not "Lightning").
A good approach to debug the debugger would be to start with a breakpoint at a point with the most shallow call stack possible (i.e. if your call stack is Class B.method <= Class A.method <= trigger on object, start with a breakpoint early in the trigger, which is at the bottom of the call stack).
Once you verify that you can, in fact, hit a breakpoint, you can start setting ones deeper in your call stack. Right now, for all you know, the code you think is being executed isn't actually being executed.
Other things that have bit me with the replay debugger:
- Make sure you're executing the code in the org you think you are using. Even small differences in code can cause issues with the debugger. I've (once or twice) pulled a log from production while trying to debug code in a developer sandbox. It didn't work very well.
- Sometimes, VSCode just needs the good, old-fashioned "turn it off and back on again". VSCode is based on Electron/Chromium (i.e. Node.js), which can work its way into some strange states. Restarting VSCode should clear out any accumulated funk from Electron/Chromium.
- If your log is too large (sounds like that may be the case here), Salesforce will truncate your log at an arbitrary point. It's quite possible that the line you're trying to break on falls into the part of the log that was truncated (and therefore the debugger can't reach that part of your code)