Feature Request: Mobile performance benchmarking (/benchmark-mobile) for React Native and iOS apps

## Summary
The existing /benchmark skill measures web performance: page load times, Core Web
Vitals, and resource sizes. There is no equivalent for native or React Native mobile
apps, where the performance model is fundamentally different. A /benchmark-mobile
skill would give mobile developers the same performance visibility that /benchmark
gives web developers.

## Current State
/benchmark is explicitly web-scoped. None of its metrics apply to a mobile app.
A React Native or iOS developer using gstack currently has no skill to answer:

- Why is my app's startup time above 2 seconds?
- Is my JS thread blocking causing frame drops?
- What is my Hermes bytecode bundle size and is it optimized?
- Which screens have excessive re-renders?
- Am I leaking memory across navigation transitions?

These require an entirely different set of tools and mental models than web
benchmarking.

## The Mobile Performance Model
Mobile app performance splits across independent layers that must be measured
separately:

JS Thread (React Native)
- Frame rate during JS-driven animations (target: 60fps / 120fps on ProMotion)
- Re-render counts per user interaction
- useMemo/useCallback effectiveness
- Bridge traffic volume or JSI call overhead

Native / Render Thread
- Time to first frame (cold start vs warm start)
- GPU overdraw and offscreen rendering
- CALayer compositing cost
- FlatList cell reuse efficiency
- Image decode and cache hit rates

Bundle & Build
- Hermes bytecode size and optimization flags
- Metro bundle analysis: which modules account for the most bytes
- Dead code elimination effectiveness
- Dynamic import and lazy loading opportunities

Memory
- Heap growth across navigation transitions (leak detection)
- Image memory pressure
- Native memory vs JS heap split

## Proposed Skill: /benchmark-mobile

Phase 1 — Startup audit
Measures cold start time, identifies the slowest initializers, flags synchronous
work on the main thread during launch, and checks the root layout for blocking
operations.

Phase 2 — JS thread profiling
Analyzes React DevTools Profiler or Flipper performance data. Identifies
components with the highest render cost, flags unnecessary re-renders, and
produces a ranked list of optimization targets.

Phase 3 — Bundle analysis
Runs bundle analysis tooling, parses the output, identifies the top 10 largest
dependencies by byte contribution, and suggests tree-shaking or lazy-loading
opportunities.

Phase 4 — Memory sweep
Navigates through the app's main flows via simulator or device session, takes
heap snapshots before and after each flow, and flags screens where heap grows
without returning to baseline.

Phase 5 — Report
Produces a structured report in the same style as /benchmark: scored dimensions,
specific findings ranked by impact, and concrete next steps with code-level
recommendations.

## Integration Points
This skill has natural hooks into existing gstack infrastructure:

- /ios-qa already drives a real iPhone over USB via CoreDevice — mobile
benchmarking could piggyback on the same connection for live profiling data
- /investigate could be called automatically when a metric falls below threshold,
beginning root-cause analysis immediately
- Language-specific reviewers could be triggered when profiling flags a
specific file as a hot path

## Why This Belongs in gstack
/benchmark exists because performance is a first-class concern before shipping.
Mobile apps have the same need. App Store ratings are heavily influenced by
performance, and Apple's guidelines flag apps that consume excessive battery
or crash on launch. A mobile developer using gstack to ship at the speed of
twenty should have the same performance safety net that web developers already
get from /benchmark.

Start by reading the existing /benchmark skill and the /ios-qa integration described in the issue, then inspect how /investigate is invoked. Scope the proposed /benchmark-mobile phases and define what a completed startup, profiling, bundle, memory, and report workflow must produce; the issue does not name implementation files or tests.

Written by the indexing model from the issue text.