ClusterEvents documentation — tombstone-removed semantics

[pathosDev]

After commit `d1199e3` (tombstone removed members), the semantics of `MemberRemoved` events changed subtly — the address now stays in `members` map indefinitely (or until #75 prunes it) with status=`removed`. Public APIs filter it out so most user code is unaffected, but a few subscribers may want to know:

• Direct subscribers to `cluster.subscribe(evt)` listening for `MemberRemoved` — same event fires, no behavioural change.
• Subscribers iterating `cluster.getMembers()` — already filtered (post-`d1199e3`).
• ShardCoordinator, Receptionist, Singleton — observe MemberRemoved + handle accordingly; all already work.

Scope:

• ClusterEvents.ts JSDoc on `MemberRemoved`: clarify "address is now tombstoned and cannot be re-added with the same identity".
• README cluster section: add a brief note on the tombstone semantics.
• If user code stored a reference to a Member instance and later checks `isReachable()`, that already returns false for `removed` — but tagging it with a comment helps.

Estimate: 0.5 days.