Expose which host a microVM was placed on (uid -> host) to clients

Hi! I'm building a GitLab CI runner on top of Brigade ([flintlock-runner](https://github.com/phoban01/flintlock-runner), still at the spec stage) and hit one gap that I think is easy to close.

The runner sends everything through the north edge: create, get, list, delete. Brigade picks the host, which is exactly what I want. But to actually run the job inside the guest I use flintlock's `MicroVMExec.ExecCommand` over vsock (sometimes `MicroVMSSHProxy`), and Brigade doesn't proxy those. So I need to open that stream against the particular `flintlockd` that's running the VM, and right now there's no way to ask Brigade which one that is.

My workaround is to call `GetMicroVM` on every host in my inventory until one of them answers. It works, and it only happens once per job, but it's a bunch of pointless round trips and it means every client of the north edge also has to know about all the hosts on the south edge, which sort of defeats the point.

Brigade already knows the answer. `Brigade.VMRecord` has `uid -> host_id` and `get_micro_vm` / `delete_micro_vm` already route on it. It just isn't exposed anywhere.

A few ways this could work, roughly cheapest first:

1. Stick a label on the `MicroVM` you hand back from create/get/list, something like `brigade.placement/host = `. No proto change, clients that don't care never notice. It'd be even nicer with the host's flintlock address as well (`brigade.placement/endpoint`), but I realise in topology A Brigade only knows `localhost:9090`, so that might have to come from host config or labels.

2. Add the placements to `GET /status`. It already lists hosts with a `vm_count`, so listing the uids (and state) under each host, or a `GET /vms/{uid}`, would be a cheap lookup without touching gRPC.

3. A proper `GetPlacement(uid)` RPC on its own service, so the flintlock `MicroVM` service stays a drop-in. Most explicit, but it's a new proto surface to look after.

I'd use (1) straight away since I already read labels off the response. This is different from #4 and #7 I think, it's about surfacing a decision Brigade has already made rather than how it talks to hosts.

Happy to put up a PR for (1) or (2) if you're open to it, just let me know which shape you'd prefer.

Start with Brigade.VMRecord and the get_micro_vm and delete_micro_vm routing paths to trace how host placement is retained. Then inspect the MicroVM responses and the GET /status surface mentioned in the issue. Done means the chosen API exposes each VM's placement consistently without requiring clients to probe every host.

Written by the indexing model from the issue text.