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

Review Lib/multiprocessing/sharedctypes.py, especially SynchronizedBase.init and the direct Synchronized, SynchronizedArray, and SynchronizedString construction paths. Reproduce the reported TypeError, then inspect the regression test mentioned in the issue and verify that direct construction succeeds without a lock or context.