feat: return 200 when a transcript upload replaces an existing language

[abhalsod-sonata]

upload_transcript (the handler behind the /transcript_upload/ endpoint used by the
Studio videos page) currently returns 201 Created whether the upload creates a
transcript for a new language or replaces an existing one. This change makes it return
200 OK when the upload replaces an existing language's transcript, keeping 201 for
first-time uploads.

Why: the in-platform transcript editor
(openedx/frontend-app-authoring#3215) saves edits by re-uploading the SRT
through this existing endpoint, and needs the create/replace distinction to give course
authors accurate feedback. The check reuses the same
new_language_code in get_available_transcript_languages(...) membership test that
validate_transcript_upload_data in this module already applies, so the semantics have
in-repo precedent.

Impacted user roles: Course Authors (via the videos-page transcript editor);
Developers/API consumers of /transcript_upload/ (see behavior-change note under
"Other information").

Diffstat: transcript_storage_handlers.py +5/−1, plus one new test in
cms/djangoapps/contentstore/views/tests/test_transcript_settings.py
(test_transcript_upload_handler_returns_200_on_replace). The pre-existing
test_transcript_upload_handler posts a new language against mocked ['en'] and
correctly continues to expect 201, unchanged.

Supporting information

• Companion frontend PR (consumes this change): feat: add in-platform transcript editor to the videos page frontend-app-authoring#3215
• Product review for the transcript editor feature:
  (feature approved; frontend-app-authoring maintainer agreed to maintain it)
• Internal (private, 2U Jira — context restated above, links included for provenance
  only): LP-910 under epic LP-735. Originally shipped downstream as
  feat: Add transcript editor toggle and update related serializers and tests edx/edx-platform#267; the feature-flag portion of that PR was dropped per product
  review, leaving only this response-code change.

Testing instructions

Automated:

pytest cms/djangoapps/contentstore/views/tests/test_transcript_settings.py -q
# (tutor: tutor dev run cms pytest cms/djangoapps/contentstore/views/tests/test_transcript_settings.py -q)

Manual (tutor dev + authoring MFE):

1. Run Studio and the authoring MFE (npm run dev, port 2001) against a course that
   has a video with at least one transcript.
2. Course → Videos → open a video's transcript row → upload/replace flow (or use the
   transcript editor from the companion PR and hit Save).
3. In the browser network tab, confirm: uploading a transcript for a new language
   returns 201; uploading again for the same language returns 200. The
   transcript content is replaced either way.

Deadline

None.

Other information

• Behavior change on an existing endpoint: the response code for the
  replace case changes from 201 → 200 (both 2xx). The authoring MFE and the legacy
  Studio video-uploads page treat any 2xx as success; flagging for any external
  clients that strictly match 201.
• Depends on nothing; the frontend PR depends on this one and should merge after it.
• No migrations, no settings changes, no feature flag (the downstream toggle was
  intentionally not ported — the feature ships enabled, per product review).
• Docs: course-author documentation will be proposed separately against
  docs.openedx.org.
• No backport to named releases requested.

[openedx-webhooks]

Thanks for the pull request, @abhalsod-sonata!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform-oncall.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Submit a signed contributor agreement (CLA)

⚠️ We ask all contributors to the Open edX project to submit a signed contributor agreement or indicate their institutional affiliation.
Please see the CONTRIBUTING file for more information.

If you've signed an agreement in the past, you may need to re-sign.
See The New Home of the Open edX Codebase for details.

Once you've signed the CLA, please allow 1 business day for it to be processed.
After this time, you can re-run the CLA check by adding a comment below that you have signed it.
If the CLA check continues to fail, you can tag the @openedx/cla-problems team in a comment for further assistance.

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[mphilbrick211]

Hi @abhalsod-sonata! Thanks for this contribution!

Are you contributing on behalf of Sonata? If so, please have your manager reach out to oscm@axim.org so we can add you to the existing entity agreement. This way we can get your CLA check to turn green, and get this reviewed for you. Thanks!

[abhalsod-sonata]

Hi @abhalsod-sonata! Thanks for this contribution!

Are you contributing on behalf of Sonata? If so, please have your manager reach out to oscm@axim.org so we can add you to the existing entity agreement. This way we can get your CLA check to turn green, and get this reviewed for you. Thanks!

CLA check resolved!.

[abhalsod-sonata]

@mphilbrick211
Can you please review and approve this PR?
CLA check is pass.