fix(services/goosefs): resolve master addresses from goosefs-site.properties (#8216)

`GoosefsBuilder::build()` overlaid `master_addr` on top of the config that
`from_properties_auto()` had already resolved, so the URI authority of
`goosefs://host:port/path` (or the `master_addr` option) always won and the
`goosefs.master.rpc.addresses` / `goosefs.master.hostname` keys of a deployed
`goosefs-site.properties` never reached the client. A client pointed at a site
file that lists the real HA masters still dialed the URI authority and failed
with a gRPC transport error.

`build()` now resolves master addresses as `GOOSEFS_MASTER_ADDR` >
`goosefs-site.properties` > `master_addr`. The site file outranks
`master_addr` because it carries a deployment's whole HA master list, which a
single URI authority cannot express, and `GOOSEFS_MASTER_ADDR` stays on top as
the per-process override. Because `from_properties_auto()` falls back to the
SDK default `127.0.0.1:9200`, the builder now asks which source actually
declared an address instead of reading the loaded value.

User-facing impact: a site file or `GOOSEFS_MASTER_ADDR` now supersedes the URI
authority and the `master_addr` option, and `build()` fails with
`ConfigInvalid` when no source supplies an address instead of silently dialing
`127.0.0.1:9200`.

Bump goosefs-sdk to 0.1.9 for RUSTSEC-2026-0002 (`lru` >= 0.16.3) and master
connection pooling. 0.1.9 does not yet honor `$GOOSEFS_CONF_DIR`;
`$GOOSEFS_CONFIG_FILE` remains the way to point at a file outside the searched
directories. Regenerated Java, .NET, and website docs for the new
`master_addr` precedence.