docs: eNet is Implemented — in eos, not here

[srpatcha]

This repository has three files: .gitignore, LICENSE, README.md. The README
said:

Status: Planned. There is no implementation in this repository yet.

The first sentence is now wrong. eNet is Implemented — 25 public functions in
eos/net/include/eos/net.h, a POSIX backend in net/src/net_posix.c, and
test_net passing in the eos suite. That is §28's definition: "feature exists
and is usable", evidenced by code and functional tests.

The second sentence stays true, and is the point: none of it is here, on purpose.

What changes

The status is corrected, so the README stops describing a subsystem that was
built three weeks ago as unstarted.

The rationale cites v2.0, which is sharper than the §24 line it replaces:

§10: Repositories should not be the dependency API.

§21.1: Do not create a separate repository merely to create a branded name. A
subsystem earns a separate repository when it has a stable interface,
independent release lifecycle, clear maintainers and multiple consumers.

It says what to do instead. The old text explained what not to do and left
the alternative implicit. Depend on eNet through a component manifest — that
format now exists (embeddedos-org/embeddedos-stack#20), and enet/wifi is its
worked example, chosen because this repository is empty.

It states the cost of getting the split wrong, because the platform is
already paying it: two independent Ed25519 implementations (eos, eBoot) and two
OTA implementations (eos, eos-health), each pair drifted — the same low-order-key
bypass in both Ed25519 copies, and eos-health's OTA calling a verification
function defined nowhere.

It names the four conditions under which this repository would earn code, so
that question has an answer instead of being re-argued.

Why not just put code here

Because §21.1's conditions are not met, and I checked each:

• stable interface — net.h is 0.x and still moving
• independent release lifecycle — eNet ships when eos ships
• distinct maintainers — none
• multiple consumers as a component — needs the manifest format, which is
  itself only just proposed

Copying eos/net/ here would create a third instance of the duplication problem
described above, in a repository whose own README warns against it.