Update "stream", "subject" occurrences in the Git integration.

[Niloth-p]

The config file is user facing, hence it needs to be updated for the integration doc to be updated.

Motivation: Updating the integration doc (user-facing, hence high priority) in #32780

This PR is intentionally kept simple.

How did you test this PR?

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.

[alya]

@laurynmm Could you please review this one?

[laurynmm]

@Niloth-p - Thanks for working on this update! The changes look fine to me, so mentioning @timabbott for an integration review.

Noting that the updates here to use "topic" instead of "subject" in the send message dict does make this inconsistent with the other documented examples for send_message in this repository. That API change to the messages endpoint dates back to Zulip 2.0, so it does feel like it should be fine to update at this point.

These updates are related to the documentation updates in zulip/zulip#32780.

[timabbott]

Let's keep it backwards-compatible; no reason to break it for existing users, given that we didn't support the new configuration method until this is merged.

This can be something like destination.get("channel", destination.get("stream")), maybe something slightly different could be needed to do errors properly; I am not sure if None would produce an ok exception in client.send_message, and I don't want an exception telling someone to add a stream field.

[timabbott]

Reviewed, ping me on chat.zulip.org when the remaining thing is resolved.

[Niloth-p]

Oops, thank you!

There was no error handling previously, errors were silently ignored.
Added some basic logging now. Log to both a log file, as well as the stderr, in case they have a better system for server stderr, whereas errors logged to the log file could be easily missed.
(Normal printing to terminal does not work in the post-receive hook.)

From the API documentation for send-message, the error messages are updated to use "channel" and not "stream". Though the codes haven't been updated.
I verified it by setting up the integration anyways. Because I wasn't familiar with the post-receive hook's behavior.

I have now verified that the error only returns {'result': 'error', 'msg': 'Missing channel', 'code': 'BAD_REQUEST'} when there's no channel value being set. So, there's no mention of a "stream", and is hence safe.

Also, I can understand if we'd want to do this renaming "stream", "subject" occurrences in all integration config files, commandline arguments and other user-facing parts, in a single pass, instead of one integration at a time. Let me know. This minimalist approach was based off of my experience with the integration docs.