chore(deps): update dependency hypothesis to v6

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
hypothesis (changelog)	4.24.6 -> 6.133.2

---

Configuration

📅 Schedule: Branch creation - "every weekend" in timezone US/Eastern, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[asajjad2]

In this upgrade, the tests began failing in CI with the error:

hypothesis.errors.InvalidArgument: Expected settings but got settings=<bound method SimpleTestCase.settings of <authentication.views_test.AuthStateTestCase testMethod=runTest>> (type=method)

The main problem here seems to be the name collision between Django's TestCase.settings method and Hypothesis settings object. Our test class inherits from both Django's HTestCase and Hypothesis's AuthStateMachine.TestCase. The auto-generated runTest method from Hypothesis calls:

run_state_machine_as_test(cls, settings=self.settings)

self.settings was resolving to Django's settings method instead of Hypothesis settings object.

This was previously being ignored but arises now probably because hypothesis 6.116.0+ introduced stricter CI type checking. Also note the error doesn't arise when the tests are run locally.

To fix this, I changed the inheritance order so Python finds Hypothesis's settings first instead of Django's. This fixed the type mismatch. From what I understand, now that the settings collision is resolved, Hypothesis can actually run the state machine test properly. But it discovered a problem with our test design, throwing

InvalidDefinition: No progress can be made from state 

Some of our test flows are "dead ends" - they start a user journey but don't lead anywhere. Specifically, when a user tries to login with an email that doesn't exist login_email_not_exists(), our test just stops there instead of continuing to registration or some other logical next step.

[asajjad2]

After fixing the Hypothesis settings collision, I've been addressing individual dead-end rules one by one (login_email_not_exists, login_password_exports_temporary_error, login_password_valid, now login_password_user_inactive), but each fix just reveals another rule with the same pattern - they consume bundles but don't produce any, causing No progress can be made from state errors. This suggests a systematic design issue rather than individual rule problems. Our auth state machine has many naturally terminal conditions (successful login, errors, edge cases) but Hypothesis expects continuous flow through bundle production or flow resets.
The whack-a-mole approach isn't working - we need either to either reduce max_example and stateful_step_count to reduce test complexity or add proper bundle flows for all terminal states, a complete top-down redesign that matches real user journey patterns.

TLDR: The fundamental issue is our bundle/flow design doesn't align with the natural terminal nature of authentication flows.