After creating venv, unconditionally find new binary.

[thatch]

Description

On archlinux with no .thx cache, things are pretty broken, at least when running with an explciit version like thx -v -p 3.9 test. It will create the .thx/venv/3.9.18/ venv but not actually use it in the subsequent attempt to update pip since it only adjusts context.python_path in the live case. Arch is special in that installing python doesn't imply installing pip automatically; venvs get it via ensurepip. I don't know if this occurs on other distros.

I think this is close to the right change, but find_runtime when passed a venv dir can still return a non-venv python and that should probably be more explicitly handled.

I think what this was doing before was either doing a --user upgrade or operating on a writable pyenv install, and not actually upgrading the one in the venv. That's my only explanation for how this wasn't erroring out.

[thatch]

Here's the repro on archlinux (looks like the python_version constraint on typing-extensions isn't quite right either, this is 3.11)

docker run -ti archlinux:latest /bin/bash
pacman -Sy
pacman -Su python git
git clone https://github.com/omnilib/thx
cd thx
python -m venv /foo
/foo/bin/pip install .
/foo/bin/pip install typing-extensions
/foo/bin/thx test

and on the official python image, debian (note that the system python 3.11 is the one that fails; 3.9 is in /usr/local)

docker run -ti python:3.9 /bin/bash
apt update
apt install python3.11-venv 
git clone https://github.com/omnilib/thx
cd thx
python -m venv /foo
/foo/bin/pip install .
/foo/bin/thx test