mention path-based matching in section on @Find methods

documentation/src/main/asciidoc/introduction/Generator.adoc

@@ -459,6 +459,15 @@ public List<Book> getBooksByTitle(String title, Type type) {
 }
 ----
 
+It's even possible to match a parameter of a finder method against a property of an associated entity or embeddable.
+The natural syntax would be a parameter declaration like `String publisher.name`, but because that's not legal Java, we can write it as `String publisher$name`, taking advantage of a legal Java identifier character that nobody ever uses for anything else:
+
+[source,java]
+----
+@Find
+List<Book> getBooksByPublisherName(String publisher$name);
+----
+
 A finder method may specify <<fetch-profiles,fetch profiles>>, for example:
 
 [source,java]

documentation/src/main/asciidoc/introduction/Introduction.adoc

@@ -613,7 +613,7 @@ So, since most persistence logic written using Hibernate 6 is _extremely_ portab
 We do need to be careful here if our persistence code uses native SQL, or if it uses concurrency-management features like pessimistic locks.
 ====
 
-Whether we're testing against your real database, or against an in-memory Java database, we'll need to export the schema at the beginning of a test suite.
+Whether we're testing against our real database, or against an in-memory Java database, we'll need to export the schema at the beginning of a test suite.
 We _usually_ do this when we create the Hibernate `SessionFactory` or JPA `EntityManager`, and so traditionally we've used a <<automatic-schema-export,configuration property>> for this.
 
 The JPA-standard property is `jakarta.persistence.schema-generation.database.action`.