multiprocessing.sharedctypes: SynchronizedBase calls get_context(force=True), which raises TypeError

Bug report

Bug description:

multiprocessing.sharedctypes.SynchronizedBase.__init__ calls get_context(force=True) when it is given neither a lock nor a ctx:

https://github.com/python/cpython/blob/20e6c2fc7c9fe5a8d62aa8f1b66a1bd72a24cf74/Lib/multiprocessing/sharedctypes.py#L187-L193

But get_context() has never accepted a force argument (set_start_method() does), so constructing one of the synchronized wrapper classes directly, without a lock or a context, fails:

>>> from multiprocessing.sharedctypes import RawValue, Synchronized
>>> Synchronized(RawValue('i', 7))
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    Synchronized(RawValue('i', 7))
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File ".../multiprocessing/sharedctypes.py", line 192, in __init__
    ctx = ctx or get_context(force=True)
TypeError: DefaultContext.get_context() got an unexpected keyword argument 'force'

The same applies to SynchronizedArray and SynchronizedString. The module-level helpers (Value(), Array(), synchronized()) are not affected because they always resolve a context themselves and pass it down, which is why this has gone unnoticed: the line dates from the commit that introduced contexts (b1694cf588, bpo-18999, 2013).

The fix is to call get_context() without the bogus argument, which is what synchronized() does a few lines above. Found by running pylint over the standard library (unexpected-keyword-arg). I have a PR with a regression test ready.

CPython versions tested on:

3.14, CPython main branch

Operating systems tested on:

macOS

Linked PRs

• gh-156063

Examinez Lib/multiprocessing/sharedctypes.py, en particulier SynchronizedBase.init et les chemins de construction directe de Synchronized, SynchronizedArray et SynchronizedString. Reproduisez le TypeError signalé, puis inspectez le test de régression mentionné dans l’issue et vérifiez que la construction directe réussit sans lock ni context.