feat(player)!: frame -> frame_no

[Naruto]

Applies the playhead stem from the API conventions (SpriteStudio-SDK#383).

frame (exported property)  ->  frame_no
get_frame / set_frame      ->  get_frame_no / set_frame_no

Why

The value is fractional — sub-frame interpolation puts the playhead between
two authored frames — and this node's own frame_updated signal already calls
its argument frame_no. The rename makes the property and the signal agree.

AnimatedSprite2D.frame is the obvious precedent to reach for, and it turned out
to be the reason to move rather than to keep: that one is an integer index into a
SpriteFrames set. A Godot reader seeing frame here is promised the wrong
type. The class reference now says exactly that where the member is documented, so
the next person who wonders finds the answer in the docs rather than in this PR.

Scope

The bound names, the exported property (including the inspector range hint that
matches on the property name), and the C++ methods behind them — which move
together so the node and SsInternalPlayer keep one word. That also carries the
editor playback panel, which seeks through them.

Class reference, API docs, the scripting guide and troubleshooting follow;
set_frame(get_frame()) — the documented force-a-redraw idiom — becomes
set_frame_no(get_frame_no()).

get_part_names() already satisfied the other half of #383, so it is untouched.

Verification

All three changed translation units compile clean with the flags from the
checked-in compile_commands.json (macOS arm64, GDExtension).

PR Build still cannot verify this — the cross-org submodule blocker is open, so
the workflow fails before reaching a compile.

Breaking, and taken now while nothing is published so no aliases are needed.