fix(targets): Make sink assertion compatible with stream maps

[JCotton1123]

The change here is necessary to ensure the assertion utilizes the aliases stream name (vs the original stream name).

Given a stream_maps config with an __alias__ configuration, see example below, a target will produce the following error:

singer_sdk.exceptions.RecordsWithoutSchemaException: A record for stream 'Account' was encountered before a corresponding schema. Check that the Tap correctly implements the Singer spec.

# meltano.yaml
...
  loaders:
  - config:
      athena_database: db
      s3_path: s3://bucket/data/
      stream_maps:
        Account:
          __alias__: Account_v2
    name: target-s3-parquet

---

📚 Documentation preview 📚: https://meltano-sdk--2589.org.readthedocs.build/en/2589/

[codspeed-hq]

CodSpeed Performance Report

Merging #2589 will not alter performance

_{Comparing JCotton1123:fix-sink-assert (532d980) with main (21821bd)}

Summary

✅ 6 untouched benchmarks

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.47%. Comparing base (21821bd) to head (532d980).
Report is 118 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2589   +/-   ##
=======================================
  Coverage   89.47%   89.47%           
=======================================
  Files          58       58           
  Lines        4798     4800    +2     
  Branches      936      937    +1     
=======================================
+ Hits         4293     4295    +2     
  Misses        352      352           
  Partials      153      153           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[edgarrmondragon]

@JCotton1123 thanks for the PR!

Can you expand on what problem this solves? The original code does smell like a bug, but I'd like to understand better what errors you're running into with the current implementation.

[JCotton1123]

@JCotton1123 thanks for the PR!

Can you expand on what problem this solves? The original code does smell like a bug, but I'd like to understand better what errors you're running into with the current implementation.

I just added a bit more detail. Let me know if I can provide more.

[edgarrmondragon]

Thanks @JCotton1123!