x,edgraph: harden reserved-namespace registration and value-lock delete coverage

[matthewmcneely]

Follow-up to #9753 (the reserved-namespace registry), addressing two hardening points from review of that work.

Registration input validation (x/keys.go)

RegisterReservedNamespace now panics at init() on two misconfigurations that previously surfaced only at mutation time:

• Namespace-qualified names. A name containing the namespace separator never matched the bare lookups, so a value-locked predicate registered in qualified form stayed publicly writable (fail open). Rejected for PredicatePrefix/Predicates/Types/ValueLocked.
• Duplicate ownership. Two namespaces (or a re-init) claiming the same predicate/type/value-lock silently last-writer-wins, letting import order pick the TrustMarker. Now panics.

Value-lock delete coverage (edgraph/server.go)

The value-lock guard (newReservedPredicateGuard) ran only on the /mutate set+del NQuad path. Two delete vectors bypassed it:

• Alter DropAttr builds its own delete edge and calls ApplyMutations directly. It now applies the same TrustMarker check, so a value-locked predicate can't be dropped by a caller lacking the owning service's marker.
• S * * delete reaches the guard with the wildcard predicate (matching no value lock), and the wildcard is expanded post-Raft in worker where the request context is gone, so it can't be enforced per-predicate at validation. Documented the boundary at the guard; bulk subject deletes that remove a value-locked predicate are gated by ACL predicate-level permissions instead.

Tests / safety

x/reserved_namespace_test.go covers the qualified-name and duplicate rejections. The DropAttr enforcement is exercised by an integration test in the consuming downstream (the value lock has no in-tree consumer, since the registry is empty in a stock build). With no registration the registry stays empty and behavior is identical to before.