When a trait declares a private method and is used by both a parent class
and a child class that re-declares the same method, Populator recorded the
child's method as "overriding" the parent's copy of the trait method. PHP
does not treat private methods as part of a class's externally visible API
and does not allow #[Override] across such a boundary, so the false
MissingOverrideAttribute forced users into invalid code that PHP itself
refuses to run.

Populator now checks the declaring method's visibility before recording it
as overridden, skipping private methods the same way it already special-
cases abstract ones a few lines above.

Fixes #10982

Cursor Bugbot flagged the new guard on Populator.php and it was right, so
this closes the gap it found.

`use T { f as public; }` does not rewrite the copied method's visibility.
Psalm keeps the adaptation in `trait_visibility_map` on the class that
applies it, and every consumer overlays it at read time (see
MethodVisibilityAnalyzer, ClassAnalyzer, FunctionLikeAnalyzer). The guard
read `$declaring_method_storage->visibility` instead, and the declaring
class here is the trait itself -- so it still saw `private` for a method
the parent exposes publicly.

The map lives on `$parent_storage` (the using class), not on the declaring
trait, so that is what the guard now consults, falling back to the stored
visibility when there is no adaptation.

Both directions were wrong before, and both are covered now:

* `as public` / `as protected` on a private trait method: the child's
  re-declaration is a real override, and MissingOverrideAttribute must
  still fire. It did not -- a false negative introduced by the guard.
* `as private` on a public trait method: the parent's method is not part
  of its visible API, so the child's method is not an override. This one
  still raised MissingOverrideAttribute -- the exact false positive this
  PR exists to remove, reached through the other adaptation.

All three new cases were checked against the unpatched tree first: the two
"promoted" cases fail without this change, the demoted case errors with
`MissingOverrideAttribute - Method B::f should have the "Override"
attribute`, and all three pass with it. The original
traitPrivateMethodRedeclaredByChildIsNotAnOverride case is unaffected.

OverrideTest 19/19, TraitTest 82/82, ClassTest 119/119, MethodSignatureTest
147 (4 pre-existing skips). parallel-lint, phpcs and Psalm's own analysis of
the changed file are all clean.

FunctionCallReturnTypeFetcher::taintReturnType() calls $stmt->getArgs() on the
taint-propagation path without checking isFirstClassCallable(). PhpParser's
CallLike::getArgs() opens with assert(!$this->isFirstClassCallable()), so under
zend.assertions=1 (PHP's development default) analysing a first-class callable of any
function with return_source_params aborts the whole run:

    $fn = strtolower(...);
    echo $fn("safe");

  AssertionError: assert(!$this->isFirstClassCallable())
  in PhpParser/Node/Expr/CallLike.php:32
  from FunctionCallReturnTypeFetcher.php:629

The same file already guards this: line 83 returns early on isFirstClassCallable(), and
line 668 guards the getArgs() at 674 with the same check. Line 629 was missed.

A first-class callable has no argument list yet, so nothing downstream can propagate taint
through arguments that do not exist; returning the node unchanged is the same thing the
sibling path at 668 already does.

Two regression tests added to TaintTest, covering a single-argument and a multi-argument
taint-propagating function. Both fail on the unpatched tree with the assertion and pass
with the fix.

Fixes #6232.

Fix function manipulator

…getargs

Fix crash on first-class callables in taint analysis

Update nikic/php-parser version to ^5.2.0

…override-fp

Fix MissingOverrideAttribute false positive for private trait methods