[Improvement] Enable independent projection across collection entities

[tywalch]

Relaxes attribute projection validation logic to allow entities to have different projection attributes. This was a constraint because the original scope of projection attributes did not include collections. By the time 3.6.0 was released, @anatolzak had done the work to enable robust collection typing, and the constraint was no longer necessary. This change removes the constraint and adds tests.

[netlify]

✅ Deploy Preview for electrodb-dev canceled.

Name	Link
🔨 Latest commit	5ecedc6
🔍 Latest deploy log	https://app.netlify.com/projects/electrodb-dev/deploys/699b5ac49cc20c00083650d1

[tywalch]

@anatolzak I am like 99% sure I imposed this constraint because the original scope didn't include collection typing, not because of any underlying implementation constraint. Lmk if you remember that and/or have any concerns.

[anatolzak]

@tywalch looks good to me. I don't think I see any issues here.

I am like 99% sure I imposed this constraint because the original scope didn't include collection typing, not because of any underlying implementation constraint. Lmk if you remember that and/or have any concerns.

I don't recall this constraint of entity projection across entities in a collection existing due to the lack of collection typing.

According to the original scope, I implemented projection typing only for non-collection queries. From a runtime perspective, you could still add different projection attributes to the schema of the entities in a collection. I think querying such a collection should have worked at runtime. However, the result type was broader because we did not consider the projection definition when computing the result type. This issue would have existed regardless of whether we added the constraint you removed in this PR.

So I don't believe there was ever a reason to add the constraint that the projection definition must match across different entities in a collection.

Let me know if I'm wrong