Fix broken apply flow: POST result is never a valid int

**Problem**

Applying to a company throws a `TypeError` before any navigation runs, so the confirm dialog freezes and no toast appears. The POST itself succeeds server-side, so students re-tap and file duplicate applications with credits deducted each time.

`makePostRequest` returns the decoded body (a `Map`) on 200, `-2` on exception, and falls off the end of the function returning `null` on any other status. The call site assigns that to a non-nullable `int`.

The backend never returns 200 here. Success is `HTTP_201_CREATED` and every validation failure is `418`, so both real paths return `null` and throw:

- 201 success -> `null` -> TypeError at the assignment, before `Navigator.pop()`. Credits are already deducted and the `Application` row already created.
- 418 validation error -> `null` -> TypeError, so the "An error occurred" toast never shows either.

The only branch that does not throw is a network exception. The `if (_apply == -1)` success check is also unreachable: `-1` is returned by `makeGetRequest`, never by `makePostRequest`.

**Where**

- `lib/screens/home/screens_for_apply/bottomModalApplySheet.dart:94-116`
- `lib/services/generic/requestService.dart:28-46` (no return after the `if` at :37-40)
- Backend contract: `omniport-app-placement-and-internship/views/application.py:169-173` (201) and `:103-110, 124-127, 135, 150-153, 176-179` (418)

**Expected**

The dialog and sheet close on success, the parent list refreshes, and validation errors surface the server's message as a toast.

**Fix sketch**

- Have `makePostRequest` return the `http.Response` instead of a decoded body or an int sentinel.
- Treat `200..299` as success and branch on that, not on `_apply == -1`.
- Surface the server's `error` field from a 418 body in the toast.
- Add `if (!mounted) return;` after the await, and drop the stale `// ignore: unused_local_variable` at :94.

**Verification**

A `MockClient` test asserting 201 is treated as success. It fails on current master.

Start with lib/screens/home/screens_for_apply/bottomModalApplySheet.dart:94-116 and lib/services/generic/requestService.dart:28-46, then compare their response handling with the backend statuses in application.py. Run or add the MockClient verification for a 201 response. Done means success closes and refreshes the sheet, while a 418 response shows its server error in a toast without a TypeError.

Written by the indexing model from the issue text.