ship: support Flutter pubspec versions with build metadata

## Problem

The `/ship` workflow assumes a root `VERSION` file containing dot-separated digits. A Flutter app can instead use `pubspec.yaml` as its release source of truth, with a standard value such as `version: 1.4.2+2049` (semantic version plus Android build number).

In a private Flutter repository with no `VERSION`, `gstack-version-bump classify --base flutter-main` reported a fresh `0.0.0.0` version even though `pubspec.yaml` contained `1.4.2+2049`. The PR-title helper then rejected the real Flutter version:

```text
error: NEW_VERSION must be dot-separated digits, got: 1.4.2+2049
```

This makes the version and PR-title invariants conflict with the application’s canonical release identity.

## Suggested behavior

- Detect Flutter repositories via `pubspec.yaml` and accept its `version:` as the version source when no explicit gstack `VERSION` source is configured.
- Preserve and validate the `+` suffix for Android/iOS build identity.
- Allow `gstack-pr-title-rewrite.sh` to generate a title such as `v1.4.2+2049 fix: ...`.
- Fail with a clear unsupported-version message instead of proposing `0.0.0.0` when a recognized ecosystem version source exists.

## Safety impact

Silently inventing `0.0.0.0` risks release-identity drift. In this run we kept `pubspec.yaml` authoritative and manually used the exact `v1.4.2+2049` PR prefix.

Start with the /ship workflow, gstack-version-bump classify --base flutter-main, and gstack-pr-title-rewrite.sh; compare their handling of VERSION with the version field in pubspec.yaml. Done means Flutter repositories use the canonical version, preserve and validate the +build suffix, produce the expected PR-title prefix, and report a clear unsupported-version error instead of 0.0.0.0.

Written by the indexing model from the issue text.