feat: add HCS-28 skill trust score/adapters specification

[kantorcodes]

Summary

• add new draft standard HCS-28 for skill trust scores/adapters
• align scoring contract and baseline adapters to current Registry Broker implementation
• add HCS-28 to standards index

What this standard defines

• skill subject model (network + name + version)
• adapter contract (id, weight, contribution mode, applicability, score fetch)
• contribution modes (conditional, universal, scoped)
• execution profiles (includeExternal=false read profile and includeExternal=true refresh profile)
• normalization and weighted aggregation rules
• baseline adapter set: upvotes, verified, metadata completeness, safety, github

Notes

This is intentionally a concrete HCS-25 profile for HCS-26 skill releases, based on the behavior currently implemented in registry-broker.

Supersedes #21 to remove prior HCS-27 branch history.

[ThoughtProof]

Thanks for putting HCS-28 together — the adapter-contract + weighted-aggregation
pattern is very readable, and the explicit separation from HCS-26 (publication)
vs HCS-28 (scoring) helps a lot when reasoning about lifecycle.

Coming from HCS-25's output-verification adapter (PR #33), five small notes
on the current v0.2 draft. All independent, all optional. Happy to open
follow-up issues for any that seem worth pursuing separately.

1. Verification-signal expiry semantics (Baseline Signal Semantics section)

The example object shows expiresAt as a SHOULD on signals with time-bound
validity (e.g. domain-control proof). The current text also says missing
signals MUST be treated as false. It might be worth stating explicitly
what happens when a signal is present but past expiresAt: is that also
false for scoring purposes, or does the profile decide? The baseline
profile probably wants false; the runtime-security profile might want
to distinguish "expired" from "never checked" for auditability.

2. Verification-adapter score keys (Verification Adapters table)

verification.review-status at 0.50 default weight is the strongest single
signal in the baseline. In our HCS-25 adapter work we ran into a related
question: whether the review that flipped verified=true should itself
be evidenced (which reviewer, against which criteria, at which point in
time). If HCS-28 leaves this to the registry implementation that's a fine
scoping choice, but a one-line note in Baseline Signal Semantics saying
so would prevent implementers from assuming HCS-28 mandates a specific
review-trail format.

3. Contribution modes and adapter overlap

conditional | universal | scoped cleanly covers most cases. One edge
case worth surfacing in the informative text: when two verification
adapters overlap in what they attest (e.g. manifest-integrity and
repo-commit-integrity both touching artifact provenance), do their
scores combine additively via the weights, or is there any deduplication
expected? Assuming additive-via-weights, a short worked example in Test
Vectors would remove ambiguity.

4. Runtime-security profile denominator

The fixed six-factor denominator is a nice interoperability guarantee.
For adapters that are conditional under the baseline profile, does
runtime-security treat their absence as zero-contribution or as
denominator-reducing? The current text implies zero-contribution but
it took a re-read; a single sentence in the Runtime Security Profile
section would help.

5. Namespacing of non-baseline adapters

The reserved namespaces (verification.*, metadata.*, upvotes,
safety.*, repository.*, and evidence.* under runtime-security)
are clearly set out. It might be worth noting explicitly whether
organization-namespaced adapters (e.g. myorg.someSignal) can emit
into a reserved namespace with a different adapterId prefix. Current
reading is "no" — worth stating.

Context for the notes above: we maintain the HCS-25 output-verification
adapter (PR #33) as a reference implementation and have been running
adapter aggregation in production for a related but different problem
(agent-decision verification, not skill-scoring). Happy to be pinged if
any of these turn into concrete decisions.