Implement named proto contracts and generic constraints

## Roadmap context

Wave keeps the existing colon-free `proto Target { ... }` form as an inherent extension. This issue tracks the separate named contract form:

```wave
proto Printable : Buffer {
fun print(self) {
// target-specific implementation
}
}
```

The block defines the named method contract and its implementation for one target at the same time. Wave should not introduce a separate signature-only interface declaration.

## Scope

- Parse and represent `proto Name : Target` separately from inherent proto blocks.
- Collect the same proto name across multiple target implementations.
- Require a matching method surface across those implementations.
- Support generic constraints such as `T: Printable`.
- Resolve constrained method calls statically.
- Reject duplicate or overlapping implementations and ambiguous method lookup.
- Preserve module visibility rules.
- Do not introduce implicit vtables, heap allocation, or runtime interface values.

## Completion criteria

- [ ] Multiple targets can implement one named proto contract.
- [ ] Method surface mismatches have source diagnostics.
- [ ] Generic functions and structs enforce proto constraints before code generation.
- [ ] Existing colon-free proto behavior remains unchanged.
- [ ] Valid and invalid cases have frontend and end-to-end regressions.

Parser-only and diagnostic-only pieces may be split into newcomer-sized issues.

Start by tracing the existing colon-free proto form through the parser and frontend, then inspect how generic constraints and method calls reach code generation. Use the existing proto behavior as the compatibility baseline and add focused frontend and end-to-end regressions for valid and invalid named contracts. Done means matching surfaces, constraints, visibility, duplicate or ambiguous implementations, and unchanged inherent proto behavior are all enforced with source diagnostics.

Written by the indexing model from the issue text.