Return 404 before 403 for order status updates

[FriggemannMichael]

Problem

A PATCH /api/orders/{id}/ on a non-existent order returned 403 instead of 404 for non-business users (customers / users without a profile). This was the single issue flagged in the mentor's acceptance review.

Root cause: IsBusinessUser was a view-level permission (has_permission), which DRF evaluates in initial() before get_object() runs. So a non-business user hit the 403 gate before the object lookup could raise the 404.

The existing test only covered the business-user case (which already returned 404), so the gap slipped through.

Fix

• Drop IsBusinessUser() from the update permissions; rely on the object-level IsOrderBusinessOwner(). Now get_object() (404) runs before the owner check (403).
• Remove the now-unused IsBusinessUser class and import from orders_app.
• Add a regression test for a non-business user patching a non-existent order → 404.

Behavior (now matches docs/endpoints.md)

Case	Status
Business owner patches own order	200
Other business user patches foreign order	403
Customer patches existing order	403
Any user patches non-existent order	404

Tests

179 passed (was 178), coverage 98.26%, ruff clean.