api-docs: Update descriptive text for stream to channel rename.

[laurynmm]

Updates the API documentation to use "channel" in descriptive text, instead of "stream". This is in keeping with how we use "organization" instead of "realm" in descriptive text in our user-facing documentation.

See relevant CZO conversations:

• https://chat.zulip.org/#narrow/stream/438-release-management/topic/rename.20.22stream.22.20to.20.22channel.22.20project.2C.20.2328468/near/1799766
• https://chat.zulip.org/#narrow/stream/378-api-design/topic/renaming.20to.20.22channel.22.20across.20API/near/1796710

Before changes:

$ git grep -i stream zerver/ | wc -l
14467
$ git grep -i stream zerver/openapi/ | wc -l
1328
$ git grep -i stream zerver/openapi/zulip.yaml | wc -l
1130
$ git grep -i stream api_docs/ | wc -l
255

After changes:

$ git grep -i stream zerver/ | wc -l
13788
$ git grep -i stream zerver/openapi/ | wc -l
653
$ git grep -i stream zerver/openapi/zulip.yaml | wc -l
455
$ git grep -i stream api_docs/ | wc -l
205

Notes:

• Does not update the operationID of any of the endpoints documented in zerver/openapi/zulip.yaml. These are used for the API documentation URLs, so we'll need to create URL redirects for the existing ones when we do make those updates.
• Does not update existing API changelog entries, but does update Changes notes related to those entries in zerver/openapi/zulip.yaml since those are in the descriptions that are being updated here.

Example screenshots:

Get subscribed channels

Current documentation

Get all channels

Current documentation

Get channel ID

Current documentation

---

Self-review checklist

• Self-reviewed the changes for clarity and maintainability
  (variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

• Explains differences from previous plans (e.g., issue description).
• Highlights technical choices and bugs encountered.
• Calls out remaining decisions and concerns.
• Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

• Each commit is a coherent idea.
• Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

• Visual appearance of the changes.
• Responsiveness and internationalization.
• Strings and tooltips.
• End-to-end functionality of buttons, interactions and flows.
• Corner cases, error conditions, and easily imagined bugs.

[zulipbot]

Hello @zulip/server-api members, this pull request was labeled with the "area: documentation (api and integrations)" label, so you may want to check it out!

[timabbott]

I'm not sure I like either test_stream or test for this sort of thing - but test_channel would be better for just making clear this is expected to be a channel name.

[timabbott]

Is the space after op: intentional? Anyway I think the colloquial "channel update event" feels better than trying to encode the event type in that format, given that we've got a link at least.

[timabbott]

I'm glad we'll be removing this style of enum-based labels in favor of the new groups-based system; this documentation is just such a mess.

[timabbott]

I posted a couple of minor comments that can potentially be addressed as follow-ups. Merged, thanks for the very organized and readable PR @laurynmm!

As a note on the operationIDs, we'll ideally want to rename with backwards-compatibility the functions in the python-zulip-api library in preparation for that sort of transition.

[laurynmm]

I think we'll also want to check with the official clients about the operationIDs also. I have a vague memory that the mobile client might look at those or reference them some how, but I'm not 100% sure on that.