[client] Let a logged-out profile deserialize again (review item 2)

ConfigFromJSON refused a document with no WireGuard or SSH key. A config
legitimately has none between a logout and the next login: mobile
LogoutProfile clears both in place and writes the profile back, so the peer
re-registers on the next login instead of returning as itself.

So the refusal broke the mobile flows it was meant to protect. On iOS and
tvOS the stored JSON of a logged-out profile stopped loading through
Client.SetConfigFromJSON and Auth.SetConfigFromJSON, and copyConfig — which
round-trips a Config through JSON to take an in-memory copy before applying
the MDM overlay — failed on the same document. Where the old code silently
minted a key, this returned an error, which is worse for logout and profile
switching alike: neither is asking to connect.

The deserializer now stays out of the identity question in both directions:
it does not generate one (a read cannot hand back keys nothing will write
down) and does not refuse one that is absent. Whoever goes on to connect is
where an absent identity has to be answered — and it already is, by the
login path that provisions and persists.

ErrConfigWithoutIdentity goes with it; nothing else used it.

client/internal/profilemanager/error.go

@@ -6,9 +6,4 @@ var (
 	ErrProfileNotFound      = errors.New("profile not found")
 	ErrProfileAlreadyExists = errors.New("profile already exists")
 	ErrNoActiveProfile      = errors.New("no active profile set")
-
-	// ErrConfigWithoutIdentity is returned for a serialized config that carries
-	// no WireGuard or SSH key. See ConfigFromJSON for why it is refused rather
-	// than provisioned.
-	ErrConfigWithoutIdentity = errors.New("config carries no peer identity: log in to provision one before loading a stored config")
 )