[tvOS] Publish dated dev builds to a Reposilite repository

[sajidalidev]

Problem

The fork releases to Maven Central with exact JetBrains version
coordinates. There is a need to publish intermittent development builds
without violating this policy.

Snapshots were rejected because they are mutable and would leak into
internal POM edges. Republishing exact versions to a dev repository was
rejected because it would poison local Gradle caches with stale entries.

A solution is needed that uses distinct version identifiers for dev
builds while preserving the principle that released coordinates carry
exact JetBrains versions.

Change

Adds a Reposilite publishing flow with dated version qualifiers
(e.g. 1.12.0-dev.20260907.1) published to an immutable releases
repository.

• mpp/build.gradle.kts: New Gradle task publishComposeJbToRemote
  targets a named Remote repository declared by MavenUploadHelper when
  publish.maven.url or MAVEN_URL is set. Credentials come from
  MAVEN_USERNAME and MAVEN_PASSWORD. Signing is skipped for dev
  builds (empty publish.signing.key); Central releases remain
  unchanged. For http:// URLs, the named Remote sets
  isAllowInsecureProtocol to opt into plain HTTP access; HTTPS URLs
  are unaffected.

• scripts/tvos-versions.sh: Single source for library version pins
  and the LIBRARIES list. Sourced by publish-tvos-fork.sh (now picks
  up pending pins: Compose 1.12.0, Material3 1.12.0-alpha03, Navigation
  2.10.0-alpha02) and the new Reposilite script.

• scripts/publish-tvos-fork-reposilite.sh: Publishes all seven
  libraries to Reposilite with dev version auto-selection (probes server
  for the first free <n> per day), mavenLocal rehearsal, closure audit,
  remote publish, and per-library verification of pom and Gradle module
  files. Outputs a consumer snippet showing repository configuration and
  versionMappings. Environment-driven: REPOSILITE_URL,
  REPOSILITE_USER, REPOSILITE_TOKEN. Flags: --no-suffix (exact
  versions for release branches), --skip-local-audit, --dry-run,
  -h. Token is passed via environment and curl stdin, never on a
  command line. Script aborts if an explicitly requested dev version
  already exists.

• scripts/audit-tvos-closure.py: Enhanced to look up library twins
  on Maven Central before deciding redirect coverage. Reports
  COVERED-BY-REDIRECT (exact twin on Central), WARN (twin at other
  versions), or FAIL (no twin anywhere). On the current tree this
  reduces false positives from 40 to 28 COVERED-BY-REDIRECT and 12
  WARN. Known gap: lifecycle-runtime-compose 2.9.6, savedstate 1.4.0,
  and savedstate-compose 1.3.6 have no twins at those versions on
  Central, documented as a known closure gap for the next release.

• ai-skills/publish-tvos-fork/SKILL.md: New "Reposilite dev builds"
  section documents when to use, version scheme, environment variables,
  flags, consumer snippet, and the rule that the shipped redirect
  manifest keeps empty mappings.

Note: scripts/stage-central-bundle.sh was left untouched (carries older
pin copies); unifying it is a follow-up.

Verification

• bash -n syntax check on all shell scripts
• ./gradlew -p mpp tasks --all confirms publishComposeJbToRemote
  is listed
• End-to-end run of scripts/publish-tvos-fork-reposilite.sh against a
  local Reposilite 3.6.3 instance published all seven libraries with
  tvOS klibs and Gradle module metadata, and per-library verification
  of the published pom and module files passed
• --dry-run mode with token masked confirmed the publish would
  proceed correctly
• Not yet run against the production server

Notes

• The shipped redirect manifest keeps empty versionMappings for dev
  versions, consumers must supply them via the printed snippet.
• Token passing follows curl stdin security practice: credentials are
  never exposed on a command line or in process arguments.
• JDK 21 and environment guards are enforced at script start.
• Exact version publishing (--no-suffix flag) is restricted to
  release--tvos and tvos-main branches.
• Plain HTTP repositories (via isAllowInsecureProtocol) are acceptable
  only on trusted LANs; HTTPS requires no additional opt-ins.