Export SONIC_BASE_CONFIG_PATH in sonic_golden_test.sh, pointing it at
the in-repo files/sonic/config_db.json next to the existing
SONIC_PORT_CONFIG_PATH, and regenerate all nine goldens against it.

The harness set no base config path before this, so the generator fell
back to /etc/sonic/config_db.json -- a path the Containerfile creates
inside the conductor image, and which does not exist on the host the
harness runs on. Every device started from {}, and the goldens pinned
output for a configuration that never occurs in production. The path
itself stopped being hardcoded when SONIC_BASE_CONFIG_PATH was added;
the harness simply never set it.

Regenerating adds 24 tables to every golden -- those populated in the
shipped base and never emitted by the generator, among them FEATURE,
TELEMETRY, SWITCH, ZTP and the POLICY_* and ECMP_LOADSHARE_* groups.
They reach real switches by passing through untouched, so nothing
covered them before. The union of populated tables across the set goes
from 38 to 62 and no golden loses one.

DEVICE_METADATA.localhost changes content rather than gaining presence,
inheriting default_config_profile, frr_mgmt_framework_config,
intf_naming_mode and type. That is INHERITED_TABLE_KEYS working as
documented: purely additive, with no generated field overwritten.

The inherited type is LeafRouter on all nine devices, spine and OOB
included, because the shipped base hardcodes it and the generator never
sets that field. That is what production gets; the empty base was hiding
it.

Verified by regenerating against a fresh stack: 3483 unit tests pass,
the committed-artifact validator accepts all nine enriched goldens, and
the golden coverage gate still passes.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Roger Luethi <luethi@osism.tech>