Fix: Decouple plugin --spec dump from core's embedded spec FS

[BlueLabelscotch]

Summary

• rootcmd.SetupAndExecutePluginRootCmd now takes specBytes []byte
  and prints them verbatim on --spec, instead of calling
  specloader.ReadSpecFile(moduleName) (which only reads names baked
  into core's pkg/spec embed.FS at compile time).
• specloader.LoadSpec now returns the bytes it read, in addition to
  registering the spec — no behavior change for existing callers
  beyond the new return value.
• Added specloader.LoadSpecBytes(reg, name, data, isHarnessUser) —
  same registration logic as LoadSpec, but the caller supplies the
  bytes directly instead of going through spec.Read.
• Updated har's main-harness-har.go to the new LoadSpec signature.

Why

go:embed globs are resolved at compile time of the declaring
package's own source directory — pkg/spec's embed can only ever see
.spec.yaml files physically committed inside
harness-unified-cli/pkg/spec/. har works today only because
har.spec.yaml happens to be checked into that directory. A plugin
that lives in a genuinely separate repo (e.g. an upcoming hcli
plugin) has no way to get its spec file into that embed, so the old
dumpSpec/ReadSpecFile path would fail for it with "file not
found." This change lets each plugin supply its own spec bytes from
wherever it likes (its own go:embed, typically), while
rootcmd/specloader stay generic.