Fix range formatting expanding to a non-source-element node - #19880

Description

Fixes #19795.

findSiblingAncestors walks up from the start node looking for a wider node that still ends inside the range, but it only compares offsets and never re-checks that what it lands on is something isSourceElement accepts. On the input from the issue it settles on the ArrowFunctionExpression, so the range ends up covering an expression, which prints as a standalone element and picks up a trailing semicolon:

beforeEach(() => {
  // c
  a();
};);

Adding the isSourceElement check to that loop fixes it. The same shape of bug hits object and class methods, except there the range lands on ObjectMethod/ClassMethod and formatting throws Missing semicolon rather than producing bad output. Fixtures for all three.

To check the blast radius I formatted 10 small sources at every possible start/end pair (about 7k ranges) and asserted the result reparses. On main, 280 ranges produced unparseable output and 154 threw; with this change both are zero, and every range that already worked produces byte-identical output.

The end-node loop just below has the same unchecked promotion. I couldn't find an input where it lands on anything but the root File, so I've left it as is.

Unrelated, but noticed while in here: calculateRange passes opts to findSiblingAncestors while findNodeAtOffset and the return value use locFunctions, which for JS is locEndWithFullText. Making that consistent changed nothing in the sweep, so I didn't fold it into this PR.

Checklist

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory).
• (If the change is user-facing) I’ve added my changes to changelog_unreleased/*/XXXX.md file following changelog_unreleased/TEMPLATE.md.
• I’ve read the contributing guidelines.
• I did not use AI to generate this PR.
• (If the above is not checked) I have reviewed the AI-generated content before submitting.