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

Lib/multiprocessing/sharedctypes.py、特に SynchronizedBase.init と、Synchronized、SynchronizedArray、SynchronizedString の直接構築経路を確認します。報告された TypeError を再現し、その後、issue で言及されているリグレッションテストを調べ、lock や context なしで直接構築が成功することを確認します。