What happened?

ArticleModel::getItem() was rewritten in 6.1.2 by #47752 to only apply an
article's own Options-tab overrides when the menu item's corresponding
field is explicitly set to the sentinel value use_article:

foreach ($menuParamsArray as $key => $value) {
    if ($value === 'use_article') {
        $articleArray[$key] = $registry->get($key) != '' ? $registry->get($key) : $globalParams->get($key);
    }
}
if (\count($articleArray)) {
    $data->params->merge(new Registry($articleArray));
}

This works for Category Blog / Archive / Featured menu item types,
whose Options forms (category/blog.xml, archive/default.xml,
featured/default.xml) do offer use_article as a selectable value for
several fields.

Single Article menu items have no such option anywhere in their form.
Neither the "Options" tab nor "Page Display" tab exposes a field whose
value can ever equal use_article. As a result, for any page reached
through a Single Article menu item, $menuParamsArray never contains the
sentinel, $articleArray is always empty, and every one of the
article's own Options-tab overrides is now silently ignored — Layout,
Title visibility, Author, Intro Text, show/hide toggles, all of it —
regardless of what the article itself has explicitly set.

Before 6.1.2, the equivalent line was a simple unconditional merge:

$data->params->merge($registry);

...which let the article's own attribs win over the menu/global params
for any key present, with no dependency on a use_article sentinel. That
behavior is what Single Article menu items actually relied on, since they
have no other mechanism to defer to the article's own settings.

Steps to reproduce:

1. Create an Article with an alternate template Layout selected in its
   own Options tab (e.g. a custom layout override other than Default).
2. Create a Single Article type menu item pointing to that article,
   leaving all Options-tab fields at their default ("Use Global").
3. Visit the menu item's page on the frontend.

Version

6.1

Expected result

The article's own Layout (and other Options-tab overrides) should be
honored, matching the behavior in 6.1.1 and earlier — since a Single
Article menu item has no field of its own to defer to the article
explicitly, the article's own setting should be treated as authoritative,
same as before #47752.

Actual result

The article's own Layout override is ignored. The page silently falls
back to the Global/menu-resolved default layout instead of the one
explicitly chosen on the article. This affects every Options-tab field on
Single Article menu items, not just Layout — it only becomes visible when
an article's explicit value differs from the Global default (for fields
where they happen to coincide, the regression is invisible).

System Information

Joomla! 6.1.2, PHP 8.3, MySQL, Apache (cPanel). Custom template with
html/com_content/article/*.php layout overrides (unrelated to the bug —
reproducible with core layouts too, since the break is entirely inside
ArticleModel::getItem()).

Additional Comments

Introduced by #47752 ("Fix Author Display Issue Using Article Setting"),
which correctly fixed the three-tier resolution for Category Blog-style
menu items but didn't account for menu item types (Single Article) that
have no use_article-capable fields at all. Suggest either:

• Falling back to the pre-#47752 unconditional merge behavior when the
  menu item type doesn't support use_article for a given key, or
• Detecting Single Article menu items specifically and preserving the
  old "article always wins" merge for them, since that's the only
  override mechanism available to that menu item type.

Happy to provide a minimal reproduction repo if useful.