Follow-up to #18571

Summary of the issue:
#18571 erroneously included its API changes in the 2025.3 section of the
changes file.

Description of user facing changes:
None

Description of developer facing changes:
API changes are correctly included in the 2026.1 section of the changes
file.

Description of development approach:
Moved lines.

Testing strategy:
None needed.

 Known issues with pull request:
None.

### Link to issue number:
Follow-up to #18571
Follow-up to #18804

### Summary of the issue:
There were a few errors in the changes introduced by #18571 that weren't
caught in #18804.

### Description of user facing changes:
None

### Description of developer facing changes:
Cosmetic fixes to changes introduced in #18571.

### Description of development approach:
Merge 2 change log items, add missing asterisk.

### Testing strategy:
None

### Known issues with pull request:
None

### Code Review Checklist:
- [x] Documentation:
  - Change log entry
  - User Documentation
  - Developer / Technical Documentation
  - Context sensitive help for GUI changes
- [x] Testing:
  - Unit tests
  - System (end to end) tests
  - Manual testing
- [x] UX of all users considered:
  - Speech
  - Braille
  - Low Vision
  - Different web browsers
  - Localization in other languages / culture than English
- [x] API is compatible with existing add-ons.
- [x] Security precautions taken.

Follow-up to #18571
Summary of the issue:

As part of #18571, I wrote code that made handling a large number of module-level deprecations easier. Since this code made handling module-level deprecations more systematic and auditable, the code was split out into its own module.
As we wanted to get #18571 merged to unblock other work, documentation for that utility was not added in that PR.
Description of user facing changes:

None
Description of developer facing changes:

Adds documentation on the novel strategy for handling module-level deprecations.
Description of development approach:

Wrote documentation.

…rom source (#18823)

Follow-up to #18571

Summary of the issue:
The deprecation helper introduced in #18571 automatically detects the
module it's being used in. This detection is broken when running a
portable or installed copy.

Description of user facing changes:
None.

Description of developer facing changes:
The module is now reported correctly when emitting deprecation warnings.

Description of development approach:
Rather than using `inspect.getmodule`, get `__name__` from the frame's
globals.

Testing strategy:
Tested importing `BLUETOOTH_ADDRESS` from `hwPortUtils` from source and
in a portable (created with `scons dist`).

Applied the following patch and attempted importing
`_remoteClient.client.seven` when running from source and portable.

```patch
diff --git a/source/_remoteClient/client.py b/source/_remoteClient/client.py
index 4691a22..541ec8f2a 100644
--- a/source/_remoteClient/client.py
+++ b/source/_remoteClient/client.py
@@ -743,3 +743,8 @@ def connectedClientsCount(self) -> int:
                        stack_info=True,
                )
                return 0
+
+from utils._deprecate import handleDeprecations, RemovedSymbol
+__getattr__ = handleDeprecations(
+       RemovedSymbol("seven", 7)
+)
```

Known issues with pull request:
None