fix(skills): every team-template skill binding now resolves

55 of 85 role skill bindings pointed at skills that were never authored,
so 10 of 11 team templates bound a smaller context bundle than their role
prompts assumed. Three roles bound nothing at all (gpu.bench_engineer,
threejs.shader_author, threejs.perf_engineer) while their prompts described
procedures they had no way to read.

The loader comment at team_template_loader.rs:167 already diagnosed this —
snake_case slugs in TOML against kebab-case skill files — and it was
half-fixed: the kebab names were corrected, the snake_case ones left.

It was invisible because both existing tests assert authored ⊆ referenced
(30/30, green) and the second explicitly declines to check the other
direction. So the failing half was the half nobody asserted.

Resolved every name by one of three explicit choices:

  - 23 skills authored where the role genuinely needed the procedure
    (gpu, threejs, research, analysis, frontend, mobile, backend, platform)
  - renames onto authored skills where one existed in substance, including
    the four-near-duplicate cases that collapse onto one real skill
  - 22 aspirational references deleted — a binding an agent cannot read is
    a promise, not a capability

Two tests now hold it. The unit test checks referenced ⊆ authored against
the files. The new integration test runs both loaders in boot order and
asserts the bindings survive the trip through the database, which is a
different question: resolution goes through skills_catalog rows, so a skill
file that exists but fails to ingest still leaves the role empty.

Negative controls: the unit test failed naming all 55; the integration test
fails naming the exact role when one name is reverted.

threejs.shader_author and .perf_engineer gained a second and third skill
after the collapse — pin_in_context pins idx < 2, so a role left with one
skill silently pins less than the policy intends.

Co-Authored-By: Claude Opus 5 <[email protected]>

skills/mobile/mobile-platform-conventions.md

@@ -0,0 +1,51 @@
+---
+name: mobile-platform-conventions
+description: Where iOS and Android genuinely differ in expected behaviour, and where a shared design is fine.
+when_to_use: You are designing a screen or flow that ships on both iOS and Android.
+tags: [mobile, design]
+---
+
+# Share the layout, respect the platform where it is muscle memory
+
+Most of a design ports unchanged. A small number of behaviours are so deeply
+learned that violating them reads as a bug rather than a style.
+
+## The differences that actually matter
+
+| | iOS | Android |
+|---|---|---|
+| Back | swipe from left edge; back button top-left | system back gesture/button — **must** work |
+| Primary nav | tab bar, bottom | bottom nav bar (or drawer) |
+| Destructive confirm | action sheet from bottom | dialog, centred |
+| Text input done | "Done" / return key | often the system back dismisses |
+| Sharing | share sheet | share intent |
+
+**System back is the one to get right.** On Android, back must always do
+something sensible: close the sheet, pop the screen, and at the root, exit.
+A screen that traps back is broken in a way users will not report — they will
+just leave.
+
+## Safe areas are not optional
+
+Notches, dynamic islands, home indicators and rounded corners all intrude.
+Anything within 16pt of an edge needs safe-area insets, not fixed padding. Test
+on a device with a notch and one without.
+
+## Touch targets
+
+44pt minimum on iOS, 48dp on Android. This is the most frequently violated rule
+in dense interfaces and the most frequently reported as "the app feels
+unreliable" rather than as a size problem.
+
+## What NOT to differentiate
+
+Content layout, spacing scale, typography hierarchy, colour and iconography can
+and should be shared. Building two visual designs doubles the work and the bugs
+for a difference users do not notice, and it is the usual reason a "platform
+conventions" pass runs over.
+
+## Test on the smallest supported device
+
+Layouts are usually designed on a large phone and break on a small one, not the
+reverse. The smallest supported screen at the largest system font size is the
+worst case, and it takes one simulator run to check.