Preserve service path types across schema APIs

[KidkArolis]

What changed

• preserve the literal transport path as the third generic on Service
• retain both schema names and transport paths through createSchema()
• export ServicePaths, ServiceByPath, and ServiceByIdentifier
• allow service utility types such as ServiceItem and ServiceQuery to resolve either namespace
• type deprecated descriptor hooks and direct Feathers access by transport path while keeping builders, relationships, and mutation proxies keyed by schema name
• extend existing inference fixtures to cover both namespaces and reject cross-namespace API usage

Why

The generated service declaration already carries both an ergonomic schema name and a literal transport path, but Figbird's service() return type discarded the path generic. Downstream consumers could therefore only recover the schema key, forcing applications with aliased paths to maintain a parallel legacy service lookup.

Preserving both identifiers in the real schema lets each API deliberately expose the namespace it actually speaks, without duplicate schemas or casts.

Impact

Applications can use one schema for named builder APIs such as q.people and m.people, while legacy hooks and raw Feathers access remain correctly typed with paths such as api/people.

Existing services without an explicit path retain their schema key as the literal default path.

Validation

• npm run tsc
• npm run lint
• npm run ava — 357 tests passed
• npm run test — type-checking, lint, formatting, coverage, and all 357 tests passed