sdk: bump the submodule past the iOS pprof fix

[Ryanmello07]

urnetwork/sdk#144 moved runtime/pprof behind !ios and merged green. This
repo still pins e3c36a9ba6, which predates it — memory_stats_pprof.go does
not exist at that commit — so the apple leg keeps rebuilding the oversized slice
and keeps failing:

[apple-size] ios-arm64-extension-sdk=55735864 bytes (53.154 MiB),
             ceiling=55574528 bytes (53.000 MiB)

Re-running CI cannot fix this. The fix was never in the tree being built.

This commit was meant to ride with #21 but missed its merge by minutes, so it is
its own PR.

Worth noting as a pattern

This is the fourth pin lag in two days:

#	pin	symptom
1	linux	Arch leg warned and skipped — make-arch.sh absent at the pin
2	extension	12 lint errors already fixed upstream
3–4	sdk	apple leg over budget, fix already merged

Every one presented as a red leg that looked like a CI defect, not as "the pin is
old". Now that each component repo builds and tests itself on push, this repo's
pins are the most likely thing to be stale — worth a periodic bump job so CI
keeps testing what the components actually ship.

What this proves either way

Whether removing pprof recovers the 161,336 bytes is measured by this build,
not asserted by it. The apple leg either clears the ceiling, or reports what is
left over — and a measured deficit is a much better thing to hand onward than
"it is too big".

[Ryanmello07]

Closing — this is structurally wrong and the CI guard was right to reject it.

All four SDK-building jobs failed in under 21 seconds with:

::error::sdk/build/go.mod carries 4 replace directive(s) pointing at sibling checkouts.
This job builds the sdk ALONE.
The build repo's recorded sdk pin has NO replace directives.

What I misunderstood

I assumed the sdk pin tracks sdk main, the way the linux and extension pins
do. It does not.

	build/go.mod replaces
sdk main	4 — .., ../../connect, ../../glog, ../../goidenticons
the recorded pin e3c36a9ba6	0

e3c36a9ba6 is refs/heads/v2026.8.21-1025763520 — a release-staged branch,
where all/run.sh has rewritten go.mod to drop the sibling replaces. Main
carries the development shape on purpose, and a job that builds the SDK alone
cannot resolve ../../connect.

So the pin is not stale. It is pinned to the right kind of commit, and bumping
it to main puts a dev-shaped module graph into a standalone build.

What actually gets the fix in

urnetwork/sdk#144 is on main, and it reaches this repo the normal way: the next
release stages a fresh v<version> branch from main with the replaces stripped,
and the pin moves to that. Nothing needs bumping by hand.

Until then the apple leg stays red for a known and understood reason, which
is different from an unexplained failure.

Correction to what I claimed in #21

I described this as "the fourth pin lag in two days". That framing was wrong for
sdk. linux (0 release branches) and extension genuinely do track main, so
those bumps were right — but sdk is release-staged by design, and lumping it in
with them produced this bad PR.