fix(standups): Autofocus the input in the discussion drawer when opened

[jmtaber129]

Description

Fixes #6873

Autofocus discussion drawer input in standup meetings.

This was previously fixed, but reverted because the autofocus was applied to all meetings (not just standups), which broke facilitator-following in other activities. This PR specifically limits the autofocus to standup meetings.

Also migrates DiscussionThreadInput to useFragment via the codeshift

Demo

https://www.loom.com/share/5cfe7f8a464f418690b32ed7e54942e1

Testing scenarios

• In a standup meeting, click the "reply" button, and confirm that the discussion autofocuses.
• Sign in as two different users in a different meeting type, and confirm that the non-facilitator follows the facilitator (see Participants don't follow facilitator in agendaItems/discuss phase #7268)

Final checklist

• I checked the code review guidelines
• I have added Metrics Representative as reviewer(s) if my PR invovles metrics/data/analytics related changes
• I have performed a self-review of my code, the same way I'd do it for any other team member
• I have tested all cases I listed in the testing scenarios and I haven't found any issues or regressions
• Whenever I took a non-obvious choice I added a comment explaining why I did it this way
• I added the label One Review Required if the PR introduces only minor changes, does not contain any architectural changes or does not introduce any new patterns and I think one review is sufficient'
• PR title is human readable and could be used in changelog

[BartoszJarocki]

lgtm!

[BartoszJarocki]

+1 no need to put editorRef in deps array, it won't trigger a rerender anyway. technically it should trigger exhuastive-deps eslint warning