hvigor-plugin 0.1.5: fix task registration, build-dir resolution, and three review findings

[Fiona2016]

Follow-up to #34. A patch release: the public type surface is a superset of 0.1.3 and
every behaviour change fixes something that could not have worked, so ^0.1.3 should
pick this up.

Do not publish yet — holding for acceptance.

Fixes

• A disabled task now says so. enabled: false returned without a word, which in a
  build log is indistinguishable from a successful upload. The option stays: in a
  pipeline, flipping a variable and editing the build command are not the same cost,
  and consumers hand-roll this gate when the plugin does not offer it.
• An empty buildDir no longer resolves to the module root. An unassigned
  FLASHCAT_BUILD_DIR= reaches the option as ''. The sourcemap search walks
  recursively, so scanning the module root collects every product's sourceMaps.map
  and uploads an arbitrary one under the current version — the same wrong-directory
  failure the product-aware default was added to prevent, reached through another
  door. Covered by a regression test.
• The demo uploads under the keys it actually reports. It was wired as
  fc-sdk-harmony-demo@0.1.0, but reports RUM as flashcat-harmony-demo (DemoConfig's
  default, and what demo_config.json ships) at 0.1.1 (AppScope versionName).
  ArkTS symbolication matches on service + version, so both keys were wrong and the
  demo — the only end-to-end surface here — could never validate symbolication.
• The plugin build gate can now fail. It ran the task and asserted nothing. With
  -p product=default the context probe's success and its fallback both resolve to
  build/default, and an upload failure never fails the build, so the step stayed
  green even if reading the product from the hvigor context was broken outright. It
  now requires the (product 'default') suffix, which only the probe path emits.
• HvigorNode.registerTask describes hvigor's API again. The optional
  dependencies/postDependencies fields were dropped because this plugin stopped
  using them, but the interface models hvigor, not this plugin's usage of it.

Also: the skip warning names the apiKey option rather than only the environment
variable and points at --no-daemon; entry/README.md documents that
hvigor-plugin/dist must be built before opening the project, since
entry/hvigorfile.ts imports it and hvigor evaluates that file on every invocation,
DevEco project sync included.

Compatibility with 0.1.3

Checked against the published 0.1.3 tarball, not by inspection:

• index.d.ts — the package's root exports are byte-identical.
• upload.d.ts, collect.d.ts, elf.d.ts — byte-identical.
• plugin.d.ts — FlashcatPluginOptions has the same fields; the only type-level
  changes are additions (getParentNode?, getContext?, resolveBuildDir). Nothing
  was removed.
• A consumer file written against the 0.1.3 documented API — flashcatSymbolUploadPlugin
  with enabled and buildDir, plus a direct uploadAll call — type-checks against
  0.1.5 under --strict with no edits.

Verification

• npm test in hvigor-plugin: 30 passing, tsc -b clean
• SDK unit tests: 148 passing
• The build-gate assertion was exercised against stubbed task output: it passes on the
  probe line, and fails both on the fallback line and on no output at all.