Fire source's propchange before cascading to dependents

[DmitrySharabin]

Summary

Props.propChanged previously cascaded to dependents first and fired the source's propchange event last. This meant el.plain = 5 produced events for computed and fnDefault before the event for plain — surprising for listeners who expect to hear about the prop they just wrote to first.

Swap the order: fire the source's event, then cascade. The cascade still runs synchronously and dependent events follow in declaration order.

Test impact

• ✅ defaultProp re-fires when its source prop changes — was red on cascade-first order, now passes.
• ✅ default() with reactive deps: synthetic prop event fires before declared and Events fan out across plain, get, and default() props — both Roll back signals and batching and reimplement them #113 baseline tests had their expectations corrected upstream on the props-behavioral-tests branch (per #113 design clarification: synthetic default props are consumer-visible, analogous to .value/.defaultValue on native form controls). They were red until source-first ordering landed; this PR makes them pass.

🤖 Generated with Claude Code

[DmitrySharabin]

Note: this PR was auto-merged by GitHub as a side effect of a restack error — the head branch was force-pushed such that it became an ancestor of the base, which GitHub interprets as "already merged." The original commit f7356e7 was preserved by cherry-picking it onto rollback-signals as commit 7b6df25, so the change is correctly landed there.