Report the hotcell-server gem version in the describe response

`Control#describe` (`hotcell-server/lib/hot_cell/control.rb:45`) answers:

```ruby
{ v: PROTOCOL_VERSION, operations: Registry.names, groups: groups, **@configuration.to_h }
```

`PROTOCOL_VERSION` is the hardcoded `1` in `hotcell-core/lib/hot_cell/protocol.rb:7` — the wire contract, which changes only when the format does. `@configuration.to_h` carries limits and scheduling. So nothing in the answer says which build of the cell is running, and `HotCell::Server::VERSION` only became a single-sourced number in 0.1.0.

Add it, so an operator can tell which cell image is deployed without shelling into the container. It is also what would let a client report a skew that the protocol version cannot see: two cells can agree on `v: 1` and still differ in behaviour, and today the only signal is that one of them answers differently.

Worth settling when doing it:

- Which version to send. `hotcell-server` is the gem that answers, but a cell's behaviour also depends on the operation gems it carries.
- Whether the client checks it. `describe_cells` already warns about a missing operation and a group mismatch; a version older than the client's is a third thing it could say at boot rather than at the first request.
- Adding a key is backward compatible, but a client that starts *requiring* it is not: a cell too old to report one has to stay readable.

Start with Control#describe in hotcell-server/lib/hot_cell/control.rb and the version definition in hotcell-core/lib/hot_cell/protocol.rb, then inspect the existing describe_cells path mentioned in the issue. Resolve which version information the response exposes and how older cells remain readable; done means the behavior and client compatibility expectations are settled.

Written by the indexing model from the issue text.