Decide when an agent may merge a dependency upgrade

An agent keeps your dependencies current: it opens one upgrade pull request per package and runs the checks. Then it has to decide whether to merge alone, wait for a person, or stop.

Write classify_dependency_upgrade(current_version, next_version, coverage_percent, touches_sensitive_area, has_breaking_note, checks_passed): the rule your agent follows for each upgrade.

• current_version, next_version (str): versions written major.minor.patch in whole numbers, for example "1.4.2".
• coverage_percent (int, 0 to 100): test coverage of the code that imports the package.
• touches_sensitive_area (bool): the package is used for auth, crypto, serialization or build tooling.
• has_breaking_note (bool): the release notes announce a breaking change.
• checks_passed (bool): tests, type checks and the canary (a small trial deploy) all passed.

It returns "auto_merge", "needs_human" or "blocked". Apply these rules in order. The first one that matches decides:

1. next_version is not newer than current_version (the same, or a downgrade): "blocked". Compare the 3 parts as numbers, left to right, so 10.2.10 is newer than 10.2.3.
2. checks_passed is false: "blocked".
3. touches_sensitive_area or has_breaking_note: "needs_human".
4. The major or minor number changed: "needs_human". Only a patch bump can merge alone.
5. coverage_percent below 80: "needs_human".
6. Otherwise: "auto_merge".

Then, in a sentence or two: why should coverage, and not just a green run, decide what merges alone?