hyp remote add does not validate the target name, so a URL-shaped or multi-line name reaches the enrollment trust notice

[bgmcmullen]

Follow-up from the review of #412 (finding 3), which is where the name became load-bearing.

Problem

runRemoteAdd (src/core/cli/remote_commands.js:234-243) validates the url argument and never the name:

if (!/^https?:\/\//.test(url)) { ... }   // url is checked
remotes[name] = { url }                  // name is not

So this is accepted:

hyp remote add https://hyp.internal https://hyp.internal/mcp

and the enrolling login then prints:

forwarding logs to the 'https://hyp.internal' server

which reintroduces exactly the autolinked dead URL #412 removed, by a different route.

A name containing a newline is likewise accepted, and splits the rule-delimited first-sync privacy block across lines.

Why it matters now

Before #412 the name appeared only in operational lines (logged in to 'prod' as org 'acme'). It is now interpolated into the enrollment trust notice pinned by LLP 0100 R1/R1a - a fixed-format consent surface. An unvalidated, config-controlled string reaching a fixed-format surface is worth closing even though every reachable path is currently benign (verified in the #412 review: no name produces a crash, undefined, or an empty label).

Suggested fix

Reject URL-shaped and whitespace-bearing names in hyp remote add. Open questions for whoever takes it:

• What exactly to reject. A conservative shape (no whitespace, no control characters, not ^https?://) is probably enough; a strict [A-Za-z0-9_.-]+ may be too narrow given the Name the server instead of printing its URL (#391) #412 review confirmed non-ASCII names like prodüktion-日本 work fine today and are a reasonable thing to want.
• Whether to validate only on write, or also defensively where the name is rendered. Config files can be hand-edited and org config layers in, so remote add is not the only way a name arrives.
• Compatibility: a machine with an already-configured bad name should not be bricked by the new check.

Scope

Behavior change to remote add, deliberately not folded into #412, which was limited to what the login prints.