docs(setup): stop naming a release version that goes stale

[JasonWildMe]

Summary

Two documentation corrections found while reviewing #37. Documentation only, no
behaviour, tooling, or version metadata changed.

• The iOS note in setup.md said the npm/Android version was
  0.1.0-field.2. It has been 0.1.0-field.6 since chore: prepare field.6 review candidate #37 merged, and the
  sentence would have gone stale again at the next bump. It now points at
  package.json and android/app/build.gradle rather than restating their
  contents. The 0.0.58 marketing version it contrasts with is unchanged and
  still accurate, so the point it was making survives.
• Records what versionCode actually is. The values look like epoch seconds
  because the first was generated that way, but field.5 and field.6 increment
  it by hand, so it no longer encodes a build time. Anyone deriving the next
  one from a clock would be guessing, and a value that lands below the
  installed build blocks the in-place upgrade testers rely on.

Also adds the missing newline at end of file, since the file was already open.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (code change that neither fixes a bug nor adds a feature)
• Chore (build process, CI, dependency updates, etc.)

Screenshots / Screen Recordings

Not applicable. No UI change.

Checklist

General

• My code follows the project's coding style and conventions
• I have performed a self-review of my code
• I have added/updated comments where the logic isn't self-evident
• My changes generate no new warnings or errors

Testing

• I have tested on Android (physical device or emulator)
• I have tested on iOS (physical device or simulator)
• I have tested in light mode and dark mode
• Existing tests pass locally (npm test)
• I have added tests that prove my fix is effective or my feature works

No code changed, so none of the above apply and no test can cover a prose
correction. The claims were verified against the tree rather than tested:

Claim	Checked against
npm version is 0.1.0-field.6	package.json
Android version is 0.1.0-field.6, code 1787551547	android/app/build.gradle
iOS marketing version is 0.0.58	project.pbxproj, single unique value
First versionCode was a real timestamp	1787551545 decodes to 2026-08-24T06:05:45Z
Later codes are hand-incremented	field.5 and field.6 are that value plus one and two seconds

A repository-wide grep found no other stale version reference in docs/ or the
README.

React Native Specific

• No new native module without corresponding platform implementation (Android + iOS) (not applicable)
• New native modules are added to the Xcode project build target (project.pbxproj) (not applicable)
• No hardcoded pixel values (not applicable)
• Styles use useThemedStyles pattern (not applicable)
• Animations/gestures work smoothly on both platforms (not applicable)
• Large lists use FlatList / FlashList (not applicable)
• No unnecessary re-renders introduced (not applicable)

Performance & Models

• Downloads / long-running tasks report progress to the UI (unchanged)
• File paths are resolved correctly on both platforms (unchanged)
• Large files (models, assets) are not committed to the repository

Security

• No secrets, API keys, or credentials are included in the code
• User input is validated/sanitized where applicable (not applicable)

Related Issues

Found while reviewing #37. Not a blocker for it, which is why it is separate.

Additional Notes

Deliberately left alone: the iOS marketing version does not track the npm and
Android version at all, so 0.1.0-field.6 describes the Android build only.
The existing text already says iOS release metadata needs separate review, and
deciding whether to align the two is a release call rather than a doc fix.

The versionCode paragraph describes the convention as it stands. If the
intent is to generate it from a clock again, the fix belongs in the release
tooling and this paragraph should change with it.

[BMichaelJ]

Reviewed the setup documentation against the npm, Android, and Xcode version metadata. No blocking issues found; this changes documentation only. Optional wording nit: "every new tester release" is more precise than "every build a tester installs", since same-version reinstalls are permitted.