fix: use juju.wait for workload version tests in k8s tutorial

[tromai]

Fixes #2646

This PR fixes the test_workload_version_set integration tests in the Example Charms in example/k8-*

The bug

From Chapter 3 onward, test_deploy waits for the charm to block, which happens immediately on the first config-changed event, as there is no database yet. This is before Pebble is ready. Then the tests move on to test_workload_version_is_set, which fails because Pebble is still not ready.

You can see it in the CI run https://github.com/canonical/operator/actions/runs/29348881449/job/87139670139#step:9:79

tests/integration/test_charm.py::test_deploy 
...
INFO     jubilant.wait:_juju.py:1491 wait: status changed:
- .apps['fastapi-demo'].app_status.current = 'waiting'
- .apps['fastapi-demo'].app_status.message = 'installing agent'
- .apps['fastapi-demo'].units['fastapi-demo/0'].workload_status.current = 'waiting'
- .apps['fastapi-demo'].units['fastapi-demo/0'].workload_status.message = 'installing agent'
- .apps['fastapi-demo'].units['fastapi-demo/0'].juju_status.current = 'allocating'
+ .apps['fastapi-demo'].app_status.current = 'blocked'
+ .apps['fastapi-demo'].app_status.message = 'Waiting for database relation'
+ .apps['fastapi-demo'].units['fastapi-demo/0'].workload_status.current = 'blocked'
+ .apps['fastapi-demo'].units['fastapi-demo/0'].workload_status.message = 'Waiting for database relation'
...
PASSED
tests/integration/test_charm.py::test_workload_version_is_set 
-------------------------------- live log call ---------------------------------
INFO     jubilant:_juju.py:398 cli: juju status --model jubilant-0a5d413e-test-charm --format json
FAILED
tests/integration/test_charm.py::test_database_integration 

Why this happened.

In #2638, I changed the order of test_workload_version_is_set to before test_database_integration. Previously, it ran after test_database_integration, so everything was okay.

The fix

We wanted to make test_workload_version_is_set independent from test_database_integration. This is okay because the workload version depends on Pebble readiness, and not the database integration.

Therefore, I use juju.wait until the workload version is available from juju status. This fits nicely into how we use Jubilant in charm integration tests.

I validated this on my fork

test_workload_version_is_set passed in CI run for Example Charm Integration Tests: https://github.com/tromai/operator/actions/runs/29554228387

I also validated that the CI still pass whether test_workload_version_is_set is before or after test_database_integration.

[dwilding]

I agree it's good to show how to wait using Jubilant built-in functionality. Thanks! I suggest one small adjustment.