hvigor-plugin 0.1.4: fix task registration and build-dir resolution

[Fiona2016]

What

uploadFlashcatSymbols could not run in 0.1.3, and when it did run it scanned the
wrong directory for every product but default. This fixes both, and removes the
option that made a skipped upload indistinguishable from a successful one.

• Task registration. The task declared dependencies: ['assembleHap','assembleHar'].
  A module has at most one of those, so the missing one failed task-graph resolution
  and stopped the build. The task now declares no build dependencies — run it as its
  own hvigor invocation after a release build, which works for HAP, HAR and HSP
  modules alike.
• Build directory. It now follows the product being built (-p product=beta →
  build/beta), read from the project's OHOS app context. It previously defaulted to
  build/default and silently scanned the wrong directory for every other product,
  which could upload a stale build's sourcemap under the new version. buildDir
  remains available as an override.
• Breaking: the enabled option is removed. With no build dependencies the task
  runs only when it is named on the command line, so naming it is already the switch.
  A second gate could only ever skip an upload that was explicitly asked for, and it
  did so without a log line. Drop enabled — and the FLASHCAT_UPLOAD variable that
  fed it — from hvigorfile.ts.
• Diagnosability. The scanned directory and how it was chosen are logged, and the
  "no sourceMaps.map found" message names the path it searched. Every path that skips
  the upload now states its reason.
• Tests. plugin.ts had none. Adds coverage for task registration and build-dir
  resolution, plus a gate in scripts/ci-check.sh that runs the task against a real
  hvigor task graph — hosted Linux CI cannot run hvigor, so a regression there is
  invisible to every other check.

Verification

• npm test in hvigor-plugin: 29 passing, tsc -b clean
• SDK unit tests: 148 passing
• Ran hvigorw uploadFlashcatSymbols --no-daemon --mode module -p module=entry@default -p product=default
  against a local DevEco toolchain: it resolves the product directory, finds the ArkTS
  sourcemap and the unstripped libentry.so, logs the upload failure against a
  deliberately unreachable endpoint, and leaves the build successful.