chore: reconcile dev into main, and make main the single trunk

[enot3615]

Answers the question from the v1.3 execution work: which branch does it build on?

main. This PR makes that true by bringing dev's one unique feature into it.

Why main, not dev

The decisive one is not a preference:

origin/main: occurrences of the old royalty code = 0   ← #42 fix present
origin/dev:  occurrences of the old royalty code = 1   ← fix ABSENT

dev still has _splitter_treasury(pm[ in python/aifinpay/unified_agent.py.
Anything built on dev inherits taking the merchant's royalty. For a branch
that is about to carry v1.3 settlement execution, that is disqualifying on its own.

The rest:

dev has never produced a release	no tags on dev that aren't on main; its only unique content is one feature from 2026-08-15
CI does not distinguish them	ci.yml triggers on bare push: / pull_request: with no branch filter, so dev buys no extra safety
No publish automation exists	releases are manual npm publish / twine, so neither branch is mechanically "the release branch" — this is a convention, and the convention has drifted twice
Protection favours main	main requires 4 status checks, dev requires 3
So does practice	7 of 11 open PRs already target main

Two long-lived branches with no mechanical difference and no promotion rule is
the actual defect. It has already cost us: main and dev diverged twice, and
a money-path fix sat on only one side of the split.

What this brings

dev's only unique content — the chain-verified internal token list (AIFINP-78,
merged to dev as #24):

12 files changed, 1665 insertions(+)

Purely additive — a new node/internal-tokenlist package, zero deletions, so
it cannot alter anything already on main. Merges clean (verified).

After this lands

1. Retarget feat(sdk): generate SPLITTER_ROUTES from the canonical registry, and fail closed on the policy window #40 to main — verified it applies cleanly there, so it costs one
   dropdown.
2. Build the v1.3 execution PR on main.
3. Delete dev, or reset it to main and agree a promotion rule before using it
   again. Recreating it without a rule recreates this PR in a month.

I am closing my #43, which reconciled main → dev. That was the right direction
only while dev was assumed to be the integration branch; it is not.

[enot3615]

Could not merge as-is: main is protected with strict, so the head branch must be up to date with the base, and dev is 3 commits behind it (#39, #41, #42). Updating dev first would mean pushing to a shared branch.

Replaced by a branch cut from main with the same content — same result, nothing pushed to dev. The reasoning for main as the trunk carries over unchanged.