Update Pipfile.lock

[ideaship]

Summary

• Regenerates Pipfile.lock using pipenv 2026.4.0, which canonicalises package names per PEP 503 before computing the Pipfile hash (pypa/pipenv#4699)
• The stored hash was stale (b670465… → 64682f1…), causing pipenv install --dev and pipenv install --deploy to fail on a fresh checkout
• Also picks up transitive dependency updates: cmd2 3.5.0→3.5.1, cryptography hash refresh (26.1→26.2), setuptools 46.0.7→47.0.0, certifi 2026.1→2026.2

Test plan

• pipenv install --dev succeeds on a fresh checkout
• pipenv install --deploy succeeds (lock is not reported as out of date)

🤖 Generated with Claude Code

[sourcery-ai]

Hey - I've left some high level feedback:

• Since this lockfile was regenerated with pipenv 2026.4.0, consider documenting or pinning that pipenv version in your tooling/CI to avoid future lockfile churn from different pipenv releases recalculating the hash differently.
• Double-check that the requires section (e.g., python_version) and any environment markers in the lockfile still match the project’s intended runtime, so that the regenerated lock doesn’t subtly change supported environments.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Since this lockfile was regenerated with pipenv 2026.4.0, consider documenting or pinning that pipenv version in your tooling/CI to avoid future lockfile churn from different pipenv releases recalculating the hash differently.
- Double-check that the `requires` section (e.g., `python_version`) and any environment markers in the lockfile still match the project’s intended runtime, so that the regenerated lock doesn’t subtly change supported environments.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}