Record a summer registration as a registration of its own

[vikrantwiz02]

A bulk course allotment for a summer term reported Successfully uploaded! inserted_rows: 61 while writing nothing at all. The summer registrations were being discarded silently.

Cause. course_registration was unique on (course_id, student_id, semester_id, registration_type). A summer term has no Semester row of its own — it anchors to the adjacent regular semester — so a summer registration of a course the student already held in that semester produced an identical key to the regular one, and bulk_create(ignore_conflicts=True) dropped it. The view then reported len(course_regs) as the number inserted, so the failure was invisible: the office saw success, and the student's courses still showed only the regular term.

Fix. semester_type joins the uniqueness key (migration 0052_course_registration_term_unique), so the two registrations are distinct rows on every code path, not just this endpoint. Adding a column to a unique key only relaxes it, so no existing row can conflict; there are no rows with a null term.

Alongside it, in allot_courses:

• the inserted count is measured against the table rather than the list that was built, and the response reports how many rows were already registered
• each row failure names the roll number, course, slot and term — previously every kind of failure surfaced as Course matching query does not exist.
• a repeat within the same term takes its type from the grade on record (Backlog or Improvement) via the existing helpers, and is reported per row when there is no grade to derive it from
• a missing academic year returns 400 instead of raising inside parse_academic_year, which was called before the required-field check

Verified against a restored copy of the live database, inside rolled-back transactions: a batch upload for a summer term writes one summer row per student beside the existing regular row, re-running the same upload adds nothing and reports every row as already registered, and the student-courses endpoint returns both registrations with their own terms. manage.py check clean, no further migrations detected.