fix(meetings): incorrect handling of control update in API responses

[marcin-bazyl]

COMPLETES #SPARK-794239

This pull request addresses

Locus sends updates for control entries in an inconsistent way. When they come in messages, the htMeta field is at the same level as the control entry key, while in API responses it is 1 level below.
For example:
locked status update in a message contains an entry like this in locusStateElements array:

{
    "htMeta": {
        "elementId": {
            "type": "ControlEntry",
            "id": 5085,
            "version": 139944494926500
        },
        "dataSetNames": [
            "main"
        ]
    },
    "data": {
        "lock": {    <------------ lock is here, so htMeta is not inside it, but outside
            "locked": true,
            "lockReason": "hostInitiate",
            "meta": {
                ...
            },                            
        }
    }
},

while in the API responses, the entry for lock status inside locus.controls looks like this:

lock: {
    "locked": false,
    "meta": {
        "lastModified": "2026-04-02T18:18:14.035Z"
    },
    "htMeta": {   <------------- htMeta is inside "lock"
        "elementId": {
            "type": "ControlEntry",
            "id": 5085,
            "version": 139944466940350
        },
        "dataSetNames": [
            "main"
        ]
    }
}

so when parsing API response, we need to keep track of the name of the parent prop and create the data object so that it contains that parent prop as the top level key.

by making the following changes

updated the code for parsing hash tree api responses.

Change Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tooling change
• Internal code refactor

The following scenarios were tested

unit tests, manual e2e test with web app on convergedats

The GAI Coding Policy And Copyright Annotation Best Practices

• GAI was not used (or, no additional notation is required)
• Code was generated entirely by GAI
• GAI was used to create a draft that was subsequently customized or modified
• Coder created a draft manually that was non-substantively modified by GAI (e.g., refactoring was performed by GAI on manually written code)
• Tool used for AI assistance (GitHub Copilot / Other - specify)
  • Github Copilot
  • Other - Please Specify
• This PR is related to
  • Feature
  • Defect fix
  • Tech Debt
  • Automation

I certified that

• I have read and followed contributing guidelines

• I discussed changes with code owners prior to submitting this pull request

• I have not skipped any automated checks

• All existing and new tests passed

• I have updated the documentation accordingly

---

Make sure to have followed the contributing guidelines before submitting.

[aws-amplify-us-east-2]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-4828.d3m3l2kee0btzx.amplifyapp.com

[mickelr]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[github-actions]

🎉 Your changes are now available!
Released in: v3.12.0-next.10
📖 View full changelog →

Packages Updated	Version
webex	3.12.0-next.10
@webex/plugin-meetings	3.12.0-next.6

Thank you for your contribution!
🤖 This is an automated message. For questions, please refer to the documentation.