There is no built in way to store dialogue state and resume after some kind of event and there are many ways to go about this (partially why I didn’t implement it). One simple way to go about it would be to separate the ‘resumed’ dialogue in another branch, and when the dialogue pausing, it can update the ‘initial branch’ to be the resuming branch. Of course you can code your own systems using custom dialogue script functions and script variables as well.
The condition column is called automatically whenever a branch is considered for display. If the script in that column returns true (be it a binary comparison, a variable with a boolean in it, or a hard coded true/false), the branch is eligible to display. It sounds like you were using this correctly in the second part.
The post-action should always run once the branch line is complete and there shouldn’t be an exception to this. That being said, we don’t make much use of hubs in our game so it maybe an issue that I simply haven’t encountered yet. We’re in the middle of a heavy crunch period at the moment, so I won’t be able to take a look at this just now.
I’m not sure if this works for what you’re trying to achieve, but you can have a silent initial branch that sets the visit variable and then moves on to your hub branch. Silent non-hub branches can most definitely run pre and post actions.