inventory show rejects --filter, and the supported-filter list has two sources of truth

## Description Two follow-ups from reviewing #51, deliberately left out of that PR to keep it focused. Both live in the same two files and are worth doing together. ## `inventory show` advertises a flag it rejects `--filter` is registered on `scan` only (`cmd/inventory.go`), while `show`'s `Short` says "Show current server inventory (same as scan)". So: ``` $ homebutler inventory show --filter exposed Error: unknown flag: --filter ``` Both commands already share `runInventoryScan`, so this is either a one-line registration or a correction to the help text. Registering it on both is probably right — "same as scan" is the promise users read, and there is no reason the filter should not apply. ## The supported-filter list has two sources of truth `RenderTreeFiltered` decides what it accepts with a `switch` (`internal/inventory/render.go:76`). `SupportedFilters()` returns a separate slice, and `IsSupportedFilter` derives from that slice. `cmd` validates against `IsSupportedFilter` before collection; `RenderTreeFiltered` validates again with the `switch`. The double validation is correct — failing before collection is better than failing after. The problem is that the two lists can disagree. Add `"listening"` to `SupportedFilters()` and forget the `case`, and the pre-check passes, then the renderer returns: ``` unsupported filter "listening" (supported: exposed, listening) ``` An error that names the value it just rejected as supported. Driving the `switch` from a map keyed by filter name, or making `IsSupportedFilter` the only gate, removes the trap. Either way the error string should be produced in one place rather than built independently in `cmd/inventory.go` and `render.go`. ## Notes Neither is user-visible today with only one filter defined. Both become live the moment a second one is added, which is when nobody will be looking for them. Follows #51, thanks @lenny-ts.