docs(apis): add client and API compatibility section

[nicpuppa]

Description

Adds documentation explaining the forward and backward compatibility guarantees between Camunda clients/SDKs and the Orchestration Cluster.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support. (add bug or support label)
• This is already available but undocumented and should be released within a week. (add available & undocumented label)
• This is on a specific schedule and the assignee will coordinate a release with the Documentation team. (create draft PR and/or add hold label)
• This is part of a scheduled alpha or minor. (add alpha or minor label)
• There is no urgency with this change (add low prio label)

PR Checklist

• The commit history of this PR is cleaned up, using {type}(scope): {description} commit message(s)

• My changes are for an upcoming minor release and are in the /docs directory (version 8.9).
• My changes are for an already released minor and are in a /versioned_docs directory.

• I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
  • Engineering team review
  • Technical writer review via @camunda/tech-writers unless working with an embedded writer.

closes camunda/camunda#41938

[github-actions]

👋 🤖 🤔 Hello, @nicpuppa! Did you make your changes in all the right places?

These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.8/.

• docs/apis-tools/working-with-apis-tools.md
• docs/reference/announcements-release-notes/890/890-announcements.md
• docs/reference/public-api.md

You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines.

[github-actions]

The preview environment relating to the commit 2c73957 has successfully been deployed. You can access it at https://preview.docs.camunda.cloud/pr-8361/

[megglos]

My understanding is that SDKs/clients are only forward-comaptible, while the API is generally backwardscompatible - old requests are processable still.

Clients are not backwardscompatible, as they may contain new functionality not present on the previous OC release. A new client may send requests the server is not capable to handle properly. E.g. a new endpoint and/or property.

That's why the upgrade path should be cluster first, then clients.

Let's align on what I might be getting wrong.

[nicpuppa]

@megglos this is the backward/forward compatibility of the client.

here the explanation case by case