Proposal: fixture-owned notes via request.add_note (refine #1376)

What's the problem this feature will solve?

Refines / supersedes #1376.

Fixtures often know useful context (DB paths, hosts, ports, etc.). Printing it loses that context in captured output. There is no first-class way for a fixture to attach notes that:

1. belong to the fixture instance (including higher scopes),
2. are available to every dependent test that uses that instance,
3. show cleanly on failure without pass-path noise,
4. are available to report consumers (TestReport, reportlog, etc.).

Item-local escapes (print, add_report_section, user_properties) do not model scoped fixture ownership.

Describe the solution you'd like

API

@pytest.fixture(scope="session")
def db(request):
    path = mk_db()
    request.add_note(f"db path: {path}")
    request.add_note({"path": str(path), "engine": "sqlite"})
    yield path

def add_note(self, note: str | dict[str, str]) -> None: ...

• Named like BaseException.add_note.
• Calls append; str or dict[str, str] in v1.
• Notes are owned by the fixture instance / its scope, not by the requesting item.

Behavior

• Notes are projected into test reports for dependents of that fixture instance (including passes, for tooling).
• Terminal shows them only on failure.
• Higher-scope notes appear on every dependent test report by design.
• Later: keep room for richer note payloads; not required in v1.

Out of scope

• First-class fixture report nodes / reworking setup-teardown attribution.
• Skipping dependents when a scoped fixture fails.
• Showing notes on passing tests in the terminal.
• Rich renderable public API in v1.

Alternative Solutions

• print / logging — unstructured, lost in capture.
• add_report_section / user_properties — item-local; wrong owner for scoped fixtures.
• Original #1376 add_info_on_failure only — too narrow for fixture-owned notes shared across dependents.

Additional context

Related: #1376. Intentional split: Holger’s failure-context need, plus fixture-owned notes visible to all dependents; larger fixture-report-node work stays separate.

No implementation file or test is named. Start by tracing the fixture request API and the report consumers mentioned in the proposal, then determine how fixture-instance ownership and scope interact with dependent reports. Done means supporting string and dictionary notes, exposing them to report consumers, showing them only on terminal failures, and preserving the listed out-of-scope behavior.